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

[Chad J]

On 07/28/2012 05:55 PM, Jonathan M Davis wrote:
> 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

What's missing then is:
- A compiler-checked and convenient/readable way of documenting what is 
being produced by an expression.
- A way to localize errors if a 3rd party breaks their API by changing 
the return type of some function I call.  "I want to make sure."
- Ease of learning.  I would definitely reach for "InputRange r = ..." 
before reaching for "auto r = ...; static assert (isInputRange!...);".

I do love auto.  I think it's awesome.  I'm just trying to explore 
what's missing, because there is something bugging me about the current 
situation.

I think it's this problem:  Reading code that declares a bunch of 
variables as "auto" can be disorienting.  Sometimes I want to put more 
specific types in my declarations instead of "auto".  This makes things 
much more readable, in some cases.  However, this is very difficult to 
do now because a bunch of stuff in Phobos returns these voldemort types. 
  I don't know what to replace the "auto" declarations with to make 
things more readable.  I'd at least like some way of specifying the 
type; a way that is as concise as the expression that yielded the type.

It reminds me of the situation in dynamically-typed languages where 
you're /forced/ to omit type information.  It's not as bad here because 
any eventual mistakes due to type mismatches are still caught at 
compile-time in D.  However, there still seems to be some amount of 
unavoidable guesswork in the current system.  There is something 
unsettling about this.