I know you haven't used generics so far so I hope this is a welcome
change - the only nuisance is that it will "break" current compilation
but will increase type safety by far.
Also added params to ICurrentRoute and inline injection notation to
$provide.decorator as per
https://github.com/borisyankov/DefinitelyTyped/issues/799
- add IHttpPromiseCallback for both `error` and `success` promise calls
use case is if we're passing around the callback, we don't want to be
repeating that entire function declaration every time, and we cannot use
`Function` as that doesn't satisfy the compiler. (see test case)
The type definition for ng.IPromise.then was, in my opinion, incorrect
semantically, and breaking on practical examples in my codebase.
An `IPromise`' `then` function takes a callback which is called with the
value of the promise once it's fulfilled. This could be a number, a
string, some object, an array of strings, anything really. Yet the
typing in angular.d.ts specified `then` as taking a `successCallback` of
type `(response: PromiseCallbackArg) => any`.
The definition of `PromiseCallbackArg` seems very permissive at first
glance, as it is defined to be an object with a bunch of fields, all
optional. Any object, a number, and a string all type check correctly
with such a type, but an array of strings, for example, does not
(`cPromise` in the provided list of test).
Furthermore, it seems to me that the `PromiseCallbackArg` definition was
added specifically to support the response type for promises returned by
the Angular `$http` service, the `ng.IHttpPromise`.
So instead of having an incorrect type on the `ng.IPromise.then` function,
I propose we return it to its generic form, and instead override the
type of the inherited `then` function in the `ng.IHttpPromise` interface.
This would also warrant renaming `PromiseCallbackArg` to
`IHttpPromiseCallbackArg`.
