If you could make any changes to D, what would they look like?

[Ola Fosheim Grøstad]

On Monday, 25 October 2021 at 16:13:25 UTC, H. S. Teoh wrote:
> I think the idea behind pure is for the compiler to enforce 
> purity in your code, since human beings are prone to making 
> mistakes.

Strong purity is useful when you use a library that takes a 
lambda expression that is meant to be used for comparison and the 
like, so you can prove that the library algorithm is correct if 
the input expression is strongly pure. D's weak purity does not 
seem to even require that the function is idempotent (that it has 
the same effect if called twice), so it does not really provide 
enough guarantees to verify the correctness of algorithms that 
take external code as input. So it isn't surprising that people 
have not found much use for it.

Being able to put constraints on lambda-parameters to functions 
is very useful in general, but you might want stronger guarantees 
than D's «pure».


>> > - shared
>> 
>> Agreed, shared is one of the biggest mess in D. This is where 
>> it is obvious where the D language designers lack in 
>> experience and knowledge. It is also a very complex issue so 
>> my advice is to rather to copy an existing design or not at 
>> all and rely more on manual concurrent "safety".
>
> Agreed.

Shared is actually one of the more promising aspects of D where 
it could stand out, but you need to be very pedantic when 
designing it (theoretical) and make sure that the resulting type 
system is sound. Meaning, you cannot allow "convenient hacks" and 
"pragmatic exceptions". It remains to be seen if D can adopt 
enough strong guarantees (be more principled) to make "shared" 
useful.

I think it is possible to define shared in a potent manner, that 
gives optimization opportunities, but I am not sure if the 
majority of D users would embrace it.


> Unfortunately this can't be changed without subtle breakage of 
> a whole ton o' code.  So, sadly, not gonna happen.

I actually think a lot of things can be changed with 
invisible-breakage if you plan for it. All you have to do is to 
extend the compiler-internal semantics to accept new features, 
without contradicting the old compiler-internal semantics. When 
it comes to syntax you could just use a language version 
identifier per source file.


> It's convenient for quick-n-dirty concurrent OO code where 
> performance isn't critical. But if you want more modern 
> concurrent techniques / high performance, yeah, it's not of 
> much use.  It's arguably dated technology.

Synchronized has runtime debt. That is a higher-level language 
design choice and not really a system level design choice. You 
could redefine the semantics so you don't have to account for it 
in the runtime, I think.