On 5/11/22 12:20, Ola Fosheim Grøstad 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.
>
> Also, if you intend to use the responses for planning purposes

No. :) I was hoping to get responses like "I come from Python and have no idea what templates are", "I come from C and have no idea what reference types are." Or exceptions, ranges, etc.

Ali

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

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

Every time I think I understand D, I don't.

Cool useful library functions like sumElement that magically don't work on static arrays.

'private' is per module, not per class, making it pretty much useless for preventing incorrect access and using .

completely different semantics for a class vs a struct. Is it a reference? Is it a value? Look up the entire declaration and have the entire Dlang manual open to find out.

As far as I remember, no automatic RAII support, even though it's insanely useful. You have to manually write scope(end) stuff which means any person forgetting one is now leaking memory.

Writing output in a deconstuctor (for learning) works. But then you accidentally combine two strings inside it and the garbage collecter crashes without a stack trace.

Documentation. Documentation. Documentation.

I just realized foreach copies by value by default. Maybe. Sometimes. When? I don't even know anymore. Because I "thought" I had to use foreach(ref) to be able to affect the original data structure (because by value means its a copy, right?). Except somehow everything has been working just fine, mutating the original structure/array from inside foreach and adding foreach(ref) makes no changes. Will it be faster? Maybe... who knows.

And I really like D! But there's lots of "WTF" moments. There's so much I have to Google for a single forum post with dead links from 2014 which is only 30% like my use-case that describes my error or problem.

On Thursday, 12 May 2022 at 01:06:02 UTC, Christopher Katko wrote:
> completely different semantics for a class vs a struct. Is it a reference? Is it a value? Look up the entire declaration and have the entire Dlang manual open to find out.
>
> As far as I remember, no automatic RAII support, even though it's insanely useful.

class = virtual functions

struct = RAII