std.functional.memoize : thread local or __gshared memoization?

[Jonathan M Davis via Digitalmars-d]

On Saturday, May 27, 2017 07:20:10 Kagamin via Digitalmars-d wrote:
> On Thursday, 25 May 2017 at 14:56:25 UTC, Jonathan M Davis wrote:
> > But we do need to get this ironed out well enough that we can
> > definitely tell folks that shared is what it's going to be so
> > that they'll stop using __gshared all over the place to try and
> > work around shared - or at least if they do so, they won't be
> > able to do so with the excuse that shared is not complete.
>
> People don't have to use shared, D supports old good "anything
> can be shared" C model, if people think C model is good enough
> for them, they can use it.

Actually, not so much, because in D, most variables are _not_ shared across
threads (unlike in C). The compiler is free to assume that if a variable is
not marked as shared, it's thread-local, and it can optimize accordingly.
Using __gshared on anything other than C globals is just begging for
trouble. As such, the fact that D programmers frequently decide to use
__gshared in order to avoid dealing with the restrictions with shared is
actually extremely bad. You can get away with it in some cases, but it's
error-prone and is only going to get worse as the compiler improves. As
such, I'd strongly argue that using __gshared with anything other than
actual C globals is a serious code smell, and it's a practice that should be
actively discouraged.

- Jonathan M Davis