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

Guillaume Piolat first.last at gmail.com
Thu May 12 23:45:47 UTC 2022


On Thursday, 12 May 2022 at 17:34:30 UTC, H. S. Teoh wrote:
>
> Why is TLS by default a problem?
>
> It's not really for optimization, AIUI, it's more for thread 
> safety: module-global state is TLS by default, so you don't 
> accidentally introduce race conditions.

What you accidentally have instead is people expecting top-level 
to be global
and instead you get TLS, so it's a surprise.
I mean, a lot of things works like C and C++, but not that.

It's a problem because it goes from solving "no accidental race 
condition" and you get "people forget to add shared or __gshared 
and their shared library silently fail" situation. You could have 
none of that with explicit TLS.

>>     - `shared static this()` vs `static this()` is another 
>> trap.
>
> One is per-process, one is per-thread.  Why is this a trap?

Well because you can get that wrong.
You get to initialize "__gshared" variables in "shared static 
this".
It's not hard, but it's something more to explain.


> I wouldn't sweat it if I couldn't easily add `pure` to an 
> entire codebase -- it hardly makes any difference anyway.

If it doesn't make a difference to the bottom-line then why keep 
it?


> you're on your own and you take responsibility for any problems 
> that you may inadvertently introduce by using the escape hatch.

Well sizeable @afe code has heaps of @trusted code, so the escape 
hatch is very routine.


> it's none of the users' business.

I'm not disagreeing about @trusted in API.
But I was remarking in practice that @safe would mean different 
invariants.
it's not a big issue, I was probably ranting.

> IOW, public APIs should always be @safe or @system. @trusted 
> should only appear on internal APIs.

Good rule to follow, TIL.


> So I'm curious, what exactly is it about UFCS chains that make 
> it less maintainable?

Probably personal preference, I mostly write the pedestrian way, 
so that debugging/optimization goes faster (maybe wrong, dunno).

In the dlang.org example:

void main()
{
     stdin
         .byLineCopy
         .array
         .sort!((a, b) => a > b) // descending order
         .each!writeln;
}

This code has a number of prerequisites to be able to read: why 
is ".array" needed, why is it ".byLineCopy" vs ".byLine", is the 
sort stable, etc. It's just requires more time spent with the 
language.



More information about the Digitalmars-d-learn mailing list