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

[IGotD-]

On Monday, 25 October 2021 at 17:17:14 UTC, Ola Fosheim Grøstad 
wrote:
>
> 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.
>
>
>> 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.

There are a few rules I've discovered with concurrent programming.

Always take the lock, don't dwell into atomic 
operations/structures too much. 99% of the cases should be 
handled by traditional mutex/semaphores and possible language 
layers above that.

Synchronized classes are good because the lock is implicit. 
However, it might be inefficient if you use several methods after 
each other which means several lock/unlock (Acquire/Release or 
whatever you name it) after each other.

One of the best designs in Rust was to combine the borrowing with 
acquiring the lock. Then you can borrow/lock on a structure do 
all the operations you want as in normal single threaded 
programming and it will be released automatically when the borrow 
goes out of scope. This is is a genius design and I'm not sure 
how to pry it into D.

Then we have the shared structs/classes in D where all basic 
types are forced to be atomic, which is totally insane. Lock free 
algorithms often consist of both normal and atomic variables. 
Also if you have several atomic variables, the operations on them 
together often introduce race conditions and your structure is 
not thread safe at all. When you are in lock free territory you 
are on your own and shared should only mean, this can be safely 
used from several threads at the same time. Compiler should do 
nothing more. Then we can also combine lock free structures with 
locked structures and where these are appropriate depends on the 
use case. Basically, the compiler should stay away from any 
further assumptions.