Deprecating this(this)

[Jonathan M Davis]

On Monday, April 02, 2018 20:47:31 Marco Leise via Digitalmars-d wrote:
> Am Mon, 2 Apr 2018 11:57:55 -0400
>
> schrieb Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org>:
> > Problem is we don't have head-mutable in the language. Yes, for built-in
> > slices the mechanism is simple - just change qualifier(T[]) to
> > qualifier(T)[]. For a struct S, there is no way to convert from
> > qualifier(S) to tailqualifier(S).
> >
> > I plan to attack this directly in the DIP - provide a way for structs to
> > express "here's what implicit conversion should be applied when doing
> > template matching".
> >
> > Andrei
>
> You are hitting a prominent type system flaw here. What may
> look like a hurdle on the path to fix this(this) is also at
> the core of getting "shared" into a good shape and probably
> affects how we will discuss "immutable destructors" and their
> kin in the future. The question is "How transitive is a
> qualifier when we strip it top-level on an aggregate?"
>
> In https://issues.dlang.org/show_bug.cgi?id=8295 I've been
> arguing for removing all qualifiers on shallow copies and the
> case you mentioned where top level qualifiers are stripped for
> template matching reconfirms me that there is generally some
> merit to that semantic, that should be explored.
>
> Shared structs need elaborate code to be copied, that's for
> sure. There may be a mutex to be used or values may be copied
> using atomic loads. The result would be what you dubbed
> "tailqualifier(S)". I.e. in case of shared, a thread-local
> copy of the fields that make up the struct.
>
> But then it starts to become messy:
> * Are there cases where we want references contained in the
>   struct to become unshared, too?
> * If yes, what if these references were marked shared
>   themselves in the struct's definition?
> * If all fields become unshared, shouldn't the now superfluous
>   mutex be removed from the struct? If so, what started out as
>   a bit blit, now produces a different type entirely.
>
> I'm interested to hear more on your thoughs on
> "tailqualifier(S)".

Copying shared structs is a bit sketchy in general. In theory, we've been
trying to make it so non-atomic operations on shared objects aren't legal,
because they're not safe unless the object is protected by a mutex. So, the
normal way to deal with shared if you want to do anything with it is to
protect a section of code with a mutex and temporarily cast away shared
within that section of code (if we had synchronized classes, then in some
cases, that cast would be automatic, but as it stands, it's always manual).
And if doing a non-atomic operation on a shared object isn't legal, then
copying a shared object doesn't really make sense. In that case, I would
expect that copying a shared object wouldn't be legal (and as such the way
to copy a shared object would be to protect that with a mutex and cast away
shared when it's copied, and then cast the new object to shared if
appropriate). On the other hand, that could get _really_ annoying, and if we
were dealing with a copy constructor rather than a postblit constructor,
then it would probably be possible to lock a mutex and inside the copy
constructor so that the copy and whatever casting was necessary could be
done safely inside the struct rather than having to externally protect it
with a mutex and cast away shared there.

So, I don't know what the answer is, but if we're trying to make operations
which aren't guaranteed to be thread-safe illegal on shared objects, then we
have a bit of a problem with what to do with copying shared objects (or
assigning shared objects). But I suppose that part of the problem is that
while the _idea_ of shared is very well defined, the actual details aren't
(e.g. a number of non-atomic operations aren't legal on shared objects, but
some are). And copying is definitely one area where that has not been
properly sorted out yet.

- Jonathan M Davis