DIP 1024--Shared Atomics--Community Review Round 1

[Ola Fosheim Grøstad]

On Sunday, 13 October 2019 at 19:23:45 UTC, Manu wrote:
> Your insistence that shared should be a library thing applies 
> equally
> to const. It behaves in an identical manner to const, and if 
> you can't
> make a compelling case for moving const to a library, you can't
> possibly sell me on that idea with respect to shared.

I'm not trying to sell anything, but you cannot easily implement 
D's const using metaprogramming as metaprogramming is realized in 
D.

You can easily extend the metaprogramming capabilities of D to 
implement shared.

Apples and Oranges.


> 1. `shared` defines D's thread-local by default semantics... 
> without
> shared, there is no thread-local by default. That decision is 
> so deep,
> there is absolutely no way to move away from that.

That argument makes no sense to me. Thread local or not thread 
local is essentially only by social agreement if you have 
syntactical means to get around it.  It is predominantly a social 
contract.

It is a matter of agreement, interpretation, conceptualization, 
mindset... That is what defines what is thread local in D. Not 
machinery.

That is not how it is in a type system that is stronger like in 
Pony. Where it is strictly enforced and clearly defined fully 
semantically in the machinery with no means to break the type 
system.

In that regard, D is not much different from C++, it is 
predominantly social and syntactical. Except in D you might have 
stronger agreement, stronger social contract, more visible 
syntactical symbols. So it appears to be stronger.

But as long as D is going to interface tightly with C/C++ it will 
always rely on social contracts.

> 2. We must be able to overload on `shared`. We can't 'overload' 
> on
> template wrappers; we can try and specialise and stuff and abuse
> clever inference and type deduction, but things break down 
> quickly. I
> have tried to simulate type qualifiers with template wrappers 
> before.
> It always goes *very* badly, and it's a mess to work with.

You have two alternatives:

1.  you can do a simple one with template wrappers.

2. you can extend the meta programming capabilities and have a 
more advanced  solution that is more in line with the current 
syntax

But it certainly is possible, and not very hard to envision. 
After all making something completely unavailable, is much easier 
than only making some aspects of an object unavailable. Which is 
why "shared" is relatively easy to do on the syntactical level in 
D, but "const" is harder. If meta-programming in D was more 
deductive then const would be fair game too, but that is not the 
case, so... it becomes less obvious and probably not worth the 
effort.


> 3. Most importantly, there is a future (not shown in this 
> discussion)
> where shared should allow some implicit promotions safely; for
> instance:

Ok, not sure if that really impacts whether it can be done in a 
library or not, but it certainly is VERY important to list such 
use-cases with sufficient detail when designing foundational 
mechanisms that is supposed to enable good interfaces to 
parallell programming libraries!