Deprecating this(this)

[Marco Leise]

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)".

-- 
Marco