Shared - Another Thread

Patrick Schluter Patrick.Schluter at bbox.fr
Thu Oct 18 19:09:42 UTC 2018


On Thursday, 18 October 2018 at 16:24:39 UTC, Manu wrote:
> On Thu., 18 Oct. 2018, 5:05 am Patrick Schluter via 
> Digitalmars-d, < digitalmars-d at puremagic.com> wrote:
>
>> On Wednesday, 17 October 2018 at 22:56:26 UTC, H. S. Teoh 
>> wrote:
>> >> If something might be used by someone else it's better not 
>> >> to touch it, unless one has confirmation it is not used by 
>> >> someone else.
>> >>
>> >> This is what shared has to enforce.
>> >
>> > Yes.  But how can the compiler statically verify this?  
>> > Because if it cannot be statically verified, then somewhere 
>> > along the line we have to trust the programmer. Ergo, it's 
>> > programming by convention, and we all know how effective 
>> > that is.
>> >
>> and that is exactly what shared is currently doing. Adding the 
>> rw restriction at least adds a protection for inadvertantly 
>> changing a shared object, a thing that doesn't exist now.
>>
>> What cracks me up with Manu's proposal is that it is its 
>> simplicity and lack of ambition that is criticized the most. 
>> shared is a clusterfuck, according to what I gathered from the 
>> forum, I never had yet to use it in my code. Manu's idea makes 
>> it a little less of a clusterfuck, and people attack the idea 
>> because it doesn't solve all and everything that's wrong with 
>> shared. Funny.
>>
>
> Elaborate on this... It's clearly over-ambitious if anything.
> What issues am I failing to address? I'm creating a situation 
> where using
> shared has a meaning, is safe, and doesn't require any unsafe 
> interactions,
> no casts, etc, for users at any level above the bare metal 
> tooling... How
> would you improve on that proposition?

No, your proposition is not the issue here. The problem I see is 
the expectation people have with what shared is supposed to do. I 
have the impression from reading in this forum about shared that 
people expect that just putting a shared in front of a variable 
will solve all the concurrency problems in existance.
Your proposition doesn't want to address this utopic goal and 
that is a good thing imo. Adding that restriction that you 
propose makes explicit what was implied but not clearly stated 
until now.
I'm not good enough in D to add more than a meta reflexion on the 
subject so I will not follow up on that. I often have the 
impression that a lot of things are going slower than necessary 
because a mentality where the perfect is in the way of good.


More information about the Digitalmars-d mailing list