While reading through the spec to resolve some impressive idiocy of mine, I noticed that alias mutability (given some constraints) is officially part of D. Previously, I knew this to be an experimental feature, and its seemingly most salient benefit is that of a more readable alternative to recursive templates. This is nice, but shouldn't a DIP have been required for its inclusion outside of the preview switch? Might I and others use it knowing that it won't be rescinded in future versions of the frontend?

On Thursday, 19 August 2021 at 06:23:52 UTC, surlymoor wrote:

If it's now official documentation, I assume that it'd need to go through a deprecation process to properly remove it, so it should be safe to use.

In regards to its inclusion into the language, I found justification in this PR:

However, there was a bit of push back:

I'm not picking sides on how this should have been approached, just trying to provide some context for this discussion.

On Thursday, 19 August 2021 at 06:23:52 UTC, surlymoor wrote:

Yes, a DIP or -preview switch should have been required. However, Walter Bright, the author and primary maintainer of D, does not always follow the official process in this regard, and he is the one who added this feature.

Since it has been included in an official release of the reference D compiler, removing it would require a deprecation period, as described in DIP 1013.

On Thursday, 19 August 2021 at 13:43:34 UTC, Paul Backus wrote:

sure... but from an external point of view, and since this is not a hot topic anymore, AliasAssign was only made to obstruct "Uplink" work on "type functions".

On Thursday, 19 August 2021 at 14:32:27 UTC, Basile B. wrote:

I think this is an uncharitable interpretation of the situation. Type functions were always extremely experimental, and it was uncertain if a complete implementation of them would ever be feasible (indeed, Stefan himself has since abandoned type functions in favor of core.reflect, for this exact reason). The point of AliasAssign was to investigate whether some of the benefits of type functions could be gained with a much simpler implementation.

On Thursday, 19 August 2021 at 15:18:46 UTC, Paul Backus wrote:

okay. But would AliasAssign have ever been proposed if the topic of type functions was not there ?

On Thursday, 19 August 2021 at 15:24:04 UTC, Basile B. wrote:

Possibly. The question that lead to type functions being proposed in the first place was "what can we do about the overhead of recursive templates?" Several possible answers were proposed, including type functions, full AST macros, enhancements to CTFE, and AliasAssign.

On Thursday, 19 August 2021 at 06:23:52 UTC, surlymoor wrote:

OMG! What if we wanted extra safety to avoid redefining it, a const alias?

On Thursday, 19 August 2021 at 15:24:04 UTC, Basile B. wrote:

In the PR comments Walter thanks Stephen for his work on type functions and mentions that it influenced AliasAssign.

On Thursday, 19 August 2021 at 15:36:00 UTC, Paul Backus wrote:

As noted, long compile times were a big motivator. Even more important, for some, was the need for a more readable/maintainable meta programming capability. Something that helped steer common usage back towards the "meta programming is just programming" ideal and away from the pain of an increasingly tortured (ab)use of templates.

Adding a new form, like core.reflect for example, undeniably makes the language broader but it can also make the language easier to use in practice: less error prone, more familiar, more debuggable, ...

We'll not drop templates but with thoughtful language addition(s) their best-practice use can evolve towards an easier-to-understand and faster-to-compile subset.