Differing levels of type-inference: Can D do this?

[Jonathan M Davis]

On Saturday, July 28, 2012 17:48:21 Chad J wrote:
> I suppose that works, but it isn't very consistent with how type safety
> is normally done.  Also it's extremely verbose.  I'd need a lot of
> convincing to chose a language that makes me write stuff like this:
> 
> auto foo = someFunc();
> static assert(isInteger!(typeof(foo));
> 
> instead of:
> 
> int foo = someFunc();
> 
> I can tolerate this in D because of the obvious difference in power
> between D's metaprogramming and other's, but it still seems very
> lackluster compared to what we could have.

Why would you even need to check the return type in most cases? It returns 
whatever range type returns, and you pass it on to whatever other range-based 
function you want to use it on, and if a template constraint fails because the 
type wasn't quite right, _then_ you go and figure out what type of range it 
returned. But as long as it compiles with the next range-based function, I 
don't see why it would matter all that much what the exact return type is. 
auto's inferrence is saving you a lot of trouble (especially when it comes to 
refactoring). Without it, most range-based stuff would be completely unusable.

- Jonathan M Davis