Which language futures make D overcompicated?

[Jonathan M Davis]

On Friday, February 09, 2018 14:48:36 jmh530 via Digitalmars-d wrote:
> On Friday, 9 February 2018 at 14:01:23 UTC, Andrea Fontana wrote:
> > [snip]
> > - Unfinished parts of language  (ex: shared?)
>
> I see this a lot, but I don't really use shared so I always
> forget how exactly it is unfinished. If there are unfinished
> parts of the language, it couldn't hurt to put in the wiki how
> exactly they are unfinished so that people don't need to keep
> asking.

The memory model needs to be properly defined like C++ finally did. It works
without that, but as I understand it, it's technically relying too much on
implementation-defined behavior.

I'm not sure if shared produces an error in all of the cases that it's
supposed to, but it might.

The druntime stuff related to shared (like mutexes, conditional variables,
and threads) isn't necessarily marked up like it should be, though some work
has been done on that with the past few releases, so it's at least better,
and it might be finished, but I'd have to dig through it to be sure.

There are some issues with shared with regards to stuff like destructors
which need to be sorted out. IIRC, a partial fix for that went in a few
months ago but causes other problems.

Synchronized classes haven't been fully implemented, so there is no
mechanism for shared to be implicitly cast away (though honestly, I don't
think that synchronized classes would do a good enough job of that to make a
significant difference, since they can only strip away the outer layer of
shared).

I think that the biggest thing is simply that too many folks don't
understand how to use it properly. They get compilation errors when they try
to use it and get mad about it and end up using __gshared, which is just
begging for bugs, because unless you're dealing with a C global, you're
almost certainly subverting the type system, since the variable is still
treated as thread-local by the type system even though it isn't.

The reality of the matter is that shared is _supposed_ to result in a bunch
of compilation errors when you try to do stuff to it. You're supposed to
either use atomics to mutate a shared object or protect it with a mutex and
temporarily cast away shared so that you can actually do stuff with it.
You're really not supposed to do much with a shared object while it's
shared, and a lot of folks don't understand that.

It would be really nice if the language had a better way to implicitly
remove shared when the object was properly protected by a mutex rather than
requiring an explicit cast, but that's _really_ hard to do (which is why
synchronized classes can only strip away the outer layer of shared). So,
ultimately, I expect that we're going to be stuck with having to use
explicit casts when using shared objects.

So, there are some rough edges in the implementation (both in the compiler
and the runtime) which need to be fixed for shared to work as well as it
should, but the design itself is generally solid. It's more a question of
folks not understanding how to use it properly and getting mad when the
compiler prevents them from doing stuff that's not thread-safe.

I suspect that part of why the lingering implementation issues haven't been
fixed is simply because so few programs actually need shared objects. It's
debatable how much of a success shared has been, but having everything be
thread-local by default has been a smashing success for the most part.

- Jonathan M Davis