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

[Arjan]

On Thursday, 12 May 2022 at 11:05:08 UTC, Basile B. wrote:
> On Wednesday, 11 May 2022 at 05:41:35 UTC, Ali Çehreli wrote:
>> What are you stuck at? What was the most difficult features to 
>> understand? etc.
>>
>> To make it more meaningful, what is your experience with other 
>> languages?
>>
>> Ali
>
> Overhall I think that D was not hard to learn because well 
> designed (i.e intuitive).

  I concur..

> A few specific points however that I remember
>
> - Certain variant forms of the `is` Expression are not obvious 
> (not intuitive), I'm pretty sure I still cant use them without 
> a quick look to the specs.

Yes indeed, had to read through the then excellent 
pdf()https://github.com/PhilippeSigaud/D-templates-tutorial by 
Philippe Sigaud (of PEG) to grasp the whole idea first, and still 
have to look it up when the need to use it arises...

>
> - Operator overloading in certain cases was confusing, I 
> remember that for one particular form once I had to use your 
> book instead of the official specs (when opSlice and opIndex 
> are combined)

Indeed same experience. Also opCmp and opEquals caused some 
confusion.

D's [][] !== C's [][],

Range peculiarities w.r.t some algo's (algo want's fwdRange but 
got inputRange but did not have the constraint ea)

lazy vs eager algorithms (the need to call .array)
>
> The main difficulty I had is actually not specific to D. It was 
> to accept that a GC is OK.

Nice one.

I recon I have to think much harder sometimes to know where the 
data is and 'who' has access: stack heap tls mutexed or not 
whatever, but find myself almost never asking this question 
anymore in D, which I use(d) to do almost all the time in c++ 
land. The need for it is almost removed by D.