Which language futures make D overcompicated?

[Mark]

On Friday, 9 February 2018 at 18:34:33 UTC, Seb wrote:
> On Friday, 9 February 2018 at 18:21:55 UTC, Bo wrote:
>> Here are a few more "basics" that are unneeded or confusing. 
>> Lets not even talk about the more advanced features like 
>> inout, ...
>>
>> /-/
>>
>> * auto: Static typed language yet we fall back on the compiler 
>> to figure out what is being assigned. Can just as well have a 
>> interpreter language. It only encourages lazy writing and has 
>> a penalty on the compilation.
>
> There's almost zero/no penalty on the compilation cost.
> What's wrong with letting the compiler help you?
> If you don't like auto, simply don't use it :O

auto is prevalent in Phobos, especially in the form of Voldemort 
types. Speaking of which, Voldemort types are an awful idea. 
Often when I use Phobos, what happens is:

1. I write something like:

import somemodule : foo, bar;
bar(foo(x)); // assume a variable x is defined beforehand

2. I get a weird, long compilation error.
3. After a lot of head scratching I realize that the problem is 
that foo(x) doesn't satisfy bar's signature constraints.
4. I go look at the signature of foo and it tells me nothing 
useful because it returns a Voldemort type.
5. I go look at the documentation of foo. Usually it is 
frustratingly terse. Can't figure out what foo promises about its 
return type (is it a forward range? If my parameter type was a 
bidirectional range, do I get a bidirectional range back?)
6. I go to the implementation of foo and look at the definition 
of its return type.

So Voldemort types make you dependent on the documentation 
capabilities of the library author. If the documentation is 
bad/outdated and you don't have the source code, well, good luck 
with that.