Deprecating this(this)

[H. S. Teoh]

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?

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


> Eduard, another student I work with, has made steps toward a
> collections library that rant into difficulties:
> 
> * @safe is achievable with relative ease
> 
> * immutable and const are very difficult, but we have an attack
> (assuming copy construction gets taken care of)

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.

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.

Also, as far as containers are concerned, the lack of a standard way to
construct head-mutable / tail-const types that works analogously with
built-in arrays makes it very difficult to write generic containers that
work well with const/immutable.  It's not too hard to make it work for
specific types, but very difficult to write a truly *generic* container
that can be deployed in all situations where const/immutable are
involved.


[...]
> * pure is difficult
[...]

The one nagging question I've been having about pure is: how much are we
actually taking advantage of the guarantees provided by pure?  We have
developed very clever ways of extending the traditional definition of
pure and invented creative ways of making more things pure, which is all
great.  But AFAIK the only place where it's actually taken advantage of
is to elide some redundant function calls inside a single expression.
And perhaps infer uniqueness in some cases for implicit casting to
immutable.

While these are indisputably useful, they seem so far to be only
relatively minor benefits.  If pure is indeed so difficult to support
generically, it begs the question, is it worth the effort just to gain
these niggling benefits?  Whatever happened to larger-scale benefits
conferred by purity?


T

-- 
Computers aren't intelligent; they only think they are.