Generality creep

[Andrei Alexandrescu]

On 3/31/19 6:25 PM, Manu wrote:
> On Sat, Mar 30, 2019 at 5:45 PM Andrei Alexandrescu via Digitalmars-d
> <digitalmars-d at puremagic.com> wrote:
>>
>> On 3/30/19 2:49 PM, Jonathan M Davis wrote:
>>> This would also be a great opportunity to fix some of the issues with shared
>>> in druntime
>>
>> The problem here is, of course, that nobody knows exactly what shared is
>> supposed to do. Not even me. Not even Walter.
> 
> As an immediate stop-gap, shared must have *no read or write access*
> to data members. Simple. Make that change. Right now.
> Then shared will at least be useful and not embarrassing, and you can
> continue to argue about what shared means while I get to work.
> 
>> One monumental piece of work would be DIP 1021 "Define the semantics of
>> shared". Then people who build with -dip1021 know what to do and what to
>> expect. Now that would patch one of the bigger holes mentioned in the
>> other post.
> 
> Sure. But in the meantime, fix the objective bug with the current
> semantics where you can read/write un-protected data freely. Right
> now. Please for the love of god.

Incidentally Walter and I discussed in the early days the idea that 
"shared" would offer no access whatsoever aside from a few special 
functions in druntime such as "atomicRead" and "atomicWrite". Of course, 
that raised the question how those functions could be implemented - the 
possible solution being some casts for typing and asm for the needed 
memory barriers.

In the end we got scared that there was no precedent in other languages, 
and we could not predict whether that would have been good or bad. The 
result is the current semantics, which should be a felony in the 48 
contiguous US states.

This does not work as a two stages process, though the "stop the 
bleeding first then come with the new solution" metaphor seems 
attractive. The main issues being when we break code that people got to 
work, we need to offer the alternative as well. Another being that the 
exact kind of things we disable/enable may be dependent on the ultimate 
solution.

This would be a large effort requiring a strong team. Walter, yourself, 
and I would be helpful participants but I think between the three of us 
we don't have the theoretical chops to pull this off. At least I know I 
don't. We need the likes of Timon Gehr, Johan Engelen, and David 
Nadlinger (whom I cc'd just in case).