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

[Ola Fosheim Grøstad]

On Monday, 25 October 2021 at 18:04:19 UTC, IGotD- wrote:
> 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.

Hm, in real-time scenarios you cannot take locks, so for system 
level programming you have to deal with atomics. It does get 
tricky real fast though… so make the data model as simple as 
possible and don't focus too much on micro-optimization in the 
beginning (just be happy if you can convince yourself that it is 
provably correct).

> 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.

Yes, I wouldn't have added the feature, but once it is there it 
is an easy to understand starting point. Monitors is also 
something that is taught at universities so it is a concept 
"generic" programmers would (should) know.

> 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.

I don't know enough about Rust's approach here, but in general, 
effective locking strategies cannot easily be formulated in a way 
that a C-ish language compiler can reason about. For that you 
would need a much more advanced layer, I think. So, not really 
realistic for D in the general case(and probably not for Rust 
either).


> Then we have the shared structs/classes in D where all basic 
> types are forced to be atomic, which is totally insane.

This is the case where D gets bitten by "being pragmatic" because 
of users pushing for convenience. And it isn't safe to allow 
access to shared state that way, or rather; it does not encourage 
correctness. Meaning, it would only be safe for very simple 
models.

What is needed is some kind of effect system that where "shared 
unaccessible" is turned into "shared accessible" (but not 
non-shared). I guess this is what Rust kinda touches upon. This 
might be difficult to do properly, so it can also be unverified 
by the compiler, but you should be able to draw "lines in the 
sand" in your code, somehow.

(I don't have the answer, but I think there are opportunities.)