Deprecating this(this)

[Andrei Alexandrescu]

On 3/31/18 8:32 PM, H. S. Teoh wrote:
> On Sat, Mar 31, 2018 at 07:38:06PM -0400, Andrei Alexandrescu via Digitalmars-d wrote:
> [...]
>> Once we have that, we can encapsulate desirable abstractions (such as
>> @nogc safe collections that work in pure code), regardless of how
>> difficult their implementations might be. It seems that currently
>> this(this) does not allow us to do that.
> 
> What exactly is it about this(this) that blocks us from doing that?

See the updated docs. Too many bugs in design and implementation.

> Removing this(this) is going to be a huge breaking change far bigger
> than, say, removing autodecoding ever will be.

We're not removing it as much as evolving it: we define an alternate 
copying mechanism, and once that is in tip-top shape, we deprecate 
this(this).

> A lot of us here have essentially given up on const except for a few
> very narrow cases.  The transitive nature of const makes it extremely
> difficult to work with in the general case, even though the simplest use
> cases are workable.

Immutable is where it's at, in terms of usefulness. Const is a mere 
servant of it (and of mutable).

> One of the biggest stumbling blocks is that whenever ranges are
> involved, const is practically out of the question, because even though
> it can be made to work for most cases, there will almost always be that
> one pathological case where it's impossible / too hard to work around,
> and that ruins it for everything else, so that it's much simpler to just
> avoid it altogether.

Yah, the DIP might address that, too. Consider:

void fun(R)(R arr)
{
     pragma(msg, typeof(arr));
}
void main()
{
     immutable(int[]) arr = [ 1, 2, 3 ];
     pragma(msg, typeof(arr));
     fun(arr);
}

The program prints during compilation:

immutable(int[])
immutable(int)[]

Interesting! So the type of the array changes during template matching, 
which is an exception to the rule that templates always glom to the 
exact type passed.

This is a hack introduced in the compiler in response to the issues you 
mention. But we don't need hacks and special casing - we need a means 
for types to say "here's what needs to happen when a template parameter 
is matched against this type".

So the DIP would address manipulating qualified ranges as a perk.

> The one nagging question I've been having about pure is: how much are we
> actually taking advantage of the guarantees provided by pure?

Very little, but that doesn't matter. The problem is it's 
underspecified. So now it's like a vague threat - whenever we mess with 
fear somebody comes asking, but what about an aggressive compiler doing 
some unexpected optimizations based on such and such interpretation?

We need to lock pure down.


Andrei