What are (were) the most difficult parts of D?

[Ali Çehreli]

On 5/11/22 11:27, templatedperson wrote:

 > I don't know if this counts as a feature, but reading the standard
 > library documentation was especially difficult. There are a ton of
 > `auto`s everywhere and function signatures are hard to read because of
 > that. I got used to confusing function signatures in a week or two, but
 > it made me consider not using D.

I agree with readability problems. And although you likely know why 
there are 'auto's everywhere in the standard library, I want to touch on 
that for others who may not know.

Although templates are great, they bring naming problems:

- Some names are overly complex and expose implementation details.

- Some names are unmentionable because the implementation chose to make 
the return type a nested struct.

import std.range;
import std.algorithm;

struct MyStruct {
}

void main() {
   auto arr = [ MyStruct() ];
   auto r = arr.map!(o => o).cycle;
   pragma(msg, typeof(r));
}

The type of the range object 'r' happens to be the scary

   Cycle!(MapResult!(__lambda2, MyStruct[])).

But make a change e.g. by adding .enumerate to the expression

   auto r = arr.map!(o => o).enumerate.cycle;

and now the type is very different (and deceptively simpler!):

   Cycle!(Result)

So, there is nothing else to do in current D but to have 'auto' return 
types.

Ali