Generality creep

[FeepingCreature]

On Monday, 1 April 2019 at 12:28:37 UTC, FeepingCreature wrote:
> I'm sorry, but there's a very great distance here, at least in 
> our codebase, between "only supposed to" (C globals) and "what 
> it's actually used for" (*any* threadshared globals). Nobody 
> wants to touch shared, but we still need threading.

Sorry for the double post, but I realized I'd forgotten to 
explain *why* we do it that way.

You will note that the way I explained threading is the way that 
basically any C-based language that doesn't have threading 
correctness as an explicit selling point does it: as a thin 
wrapper around pthreads. It's the "natural", "normal" way to do 
threading, the way that programmers have been doing it for 
literal decades. Threads and mutexes.

If D wants people to do it in a different way, that solution 
needs to be slick, operational and *reliable*. Any solution that 
starts with "well you can just cast it away cause it doesn't 
really work yet" doesn't have the reaction of "well we're just 
gonna do it that way then, because there's no other way, and hope 
the D devs clean up shared one of these *years*" - the reaction 
is going to be the entirely predictable "well, we're just gonna 
go back to the C way then." That's where D is right now, and 
that's why I look at all the discussion about shared with a kind 
of amused bewilderment. Thread safety is simply fundamentally not 
about exposing atomic access to data in our minds. Thread safety 
is about having classes, that own data, access to which they can 
lock to one thread. Synchronized(this). That's the established, 
commonsense, baseline idiom. It shouldn't be surprising that we 
prefer it to randomly casting away modifiers that the language 
randomly forces on us despite them being highly experimental and 
subject to change.

Get the normal, established way to do threading working 
consistently and reliably *now*. Then think about shared.

That's my opinion, at least.