Provide an overload for $timeout that doesn't take a function

[benjamingr]

I propose a $timeout variant that takes only a duration parameter.

There are two primary use cases I can think of

It would be really nice to be able to do:

$timeout(100).then(function(){
    // do stuff here, this runs a digest if it needs to which the
    // $timeout(function()... variant does not since 19b6b34
})

As well as

myServiceFn().then(function(res){
    // do something
    return $timeout(300);
}).then(function(){...

Which is rather common and today is accomplished by return $timeout(angular.noop, 300) which feels redundant and rather ugly.

This could be accomplished by adding a simple check here and I wouldn't mind creating a PR if you would entertain one.

[lgalfaso]

This looks reasonable

[gkalpak]

According to @caitp (#9175 (comment)) $timeout should still invoke $apply() if the invokeApply argument is not specified or truthy (if it doesn't then it is a bug and should be fixed).

If that is indeed the case, then I don't see this change making any difference.

[caitp]

yes, I'm going to see if I can reproduce what they're talking about, because this was tested manually before

[caitp]

http://jsbin.com/tesaqovopaza/1/edit can't reproduce at all

[caitp]

Wait hang on, these things are talking about two very different issues ^_^

[gkalpak]

@caitp:
What I said is that if the other issue is not an issue (i.e. if $timeout is working as expected), then the modification proposed in this issue is not particularly valuable.

I.e. everything that will be possible using $timeout(100).then(callback) is already possible using $timeout(callback, 100). (It's even less code with the current implementation.)

[caitp]

yeah, I sort of agree that it's a weird feature to add, but if people really want it, it probably won't account for much code

[benjamingr]

@caitp here is a fiddle illustrating it working after a .then -http://jsfiddle.net/c8rchefp/ here is it not assimilating a promise without a .then http://jsfiddle.net/x4y3kjzf/ which is not what I'd expect.

After a second check this is not the breaking change since promises returning promises don't schedule a digest at the current moment anyway (although that's not the behavior I'd expect).

I'm still all for this feature though for the promise chain use case regardless of this. I'll close the PR on the other issue, my bad.

[caitp]

http://jsfiddle.net/3n9akpdg/ --- works this way. It looks like something is wrong with the way we're dealing with external promises, you should file a bug on $q

[benjamingr]

@caitp it's not a bug since the digest system is completely orthogonal to the concerns of the Promises/A+ specification. Looking back at how $q behaves in 1.2 this is not a change. The overload is still nice for the promise chain case.

I'll write a PR for this in the next few days and accompanying tests.