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.
