www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Is AliasAssign Now Official?

reply surlymoor <surlymoor cock.li> writes:
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](https://dlang.org/spec/declaration.html#AliasAssign). 
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?
Aug 18 2021
next sibling parent Dylan Graham <dylan.graham2000 gmail.com> writes:
On Thursday, 19 August 2021 at 06:23:52 UTC, surlymoor wrote:

 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](https://dlang.org/spec/declaration.html#AliasAssign). 
 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?


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](https://github.com/dlang/dmd/pull/11846):


 I'm trying to convince myself that this is removal of 
 surprising limitations, as opposed to a large change. On the 
 face of it, allowing reassignment of alias names is in keeping 
 with the rest of D (mutability is the default). So I could 
 imagine how we can consider that as removing a limitation. 
 [link](https://github.com/dlang/dmd/pull/11846#issuecomment-706615742)


However, there was a bit of push back:

 It would be great if we could stop putting experimental stuff 
 straight into the language.


There's nothing wrong with iterative design and experimental 
features, but they should be opt-in, behind a preview switch. 
[link](https://github.com/dlang/dmd/pull/11846#issuecomment-745501942)

I'm not picking sides on how this should have been approached, 
just trying to provide some context for this discussion.
Aug 19 2021
prev sibling next sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Thursday, 19 August 2021 at 06:23:52 UTC, surlymoor wrote:

 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](https://dlang.org/spec/declaration.html#AliasAssign). 
 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?


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.


 Might I and others use it knowing that it won't be rescinded in 
 future versions of the frontend?


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][1].

[1]: 
https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1013.md
Aug 19 2021
parent reply Basile B. <b2.temp gmx.com> writes:
On Thursday, 19 August 2021 at 13:43:34 UTC, Paul Backus wrote:

 [...]
 Yes, a DIP or -preview switch should have been required. 
 However, Walter Bright, the author and primary maintainer of D, 
 [...]


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".
Aug 19 2021
parent reply Paul Backus <snarwin gmail.com> writes:
On Thursday, 19 August 2021 at 14:32:27 UTC, Basile B. wrote:

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

 [...]
 Yes, a DIP or -preview switch should have been required. 
 However, Walter Bright, the author and primary maintainer of 
 D, [...]


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


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.
Aug 19 2021
parent reply Basile B. <b2.temp gmx.com> writes:
On Thursday, 19 August 2021 at 15:18:46 UTC, Paul Backus wrote:

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

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

 [...]
 Yes, a DIP or -preview switch should have been required. 
 However, Walter Bright, the author and primary maintainer of 
 D, [...]


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


 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.


okay. But would AliasAssign have ever been proposed if the topic 
of type functions was not there ?
Aug 19 2021
next sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Thursday, 19 August 2021 at 15:24:04 UTC, Basile B. wrote:

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


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.
Aug 19 2021
parent Bruce Carneal <bcarneal gmail.com> writes:
On Thursday, 19 August 2021 at 15:36:00 UTC, Paul Backus wrote:

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

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


 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.


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.
Aug 19 2021
prev sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 19 August 2021 at 15:24:04 UTC, Basile B. wrote:

 [snip]

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


In the PR comments Walter thanks Stephen for his work on type 
functions and mentions that it influenced AliasAssign.
Aug 19 2021
parent reply Basile B. <b2.temp gmx.com> writes:
On Thursday, 19 August 2021 at 16:56:22 UTC, jmh530 wrote:

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

 [snip]

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


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


smart evil
Aug 19 2021
parent reply Basile B. <b2.temp gmx.com> writes:
On Thursday, 19 August 2021 at 19:54:09 UTC, Basile B. wrote:

 On Thursday, 19 August 2021 at 16:56:22 UTC, jmh530 wrote:

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

 [snip]

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


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


 smart evil


to be honest:

The situation is like we have now a feature nobody gives a shit 
about.
While type functions should have been something big and 
interesting.

I suspect that this feature nobody cares about was motivated by
the newCTFE failure, which has caused a serious trusting issue in 
Stefan work.

I cannot be more honnest. This is really what I think.
Aug 19 2021
next sibling parent Basile B. <b2.temp gmx.com> writes:
On Thursday, 19 August 2021 at 20:16:19 UTC, Basile B. wrote:

 On Thursday, 19 August 2021 at 19:54:09 UTC, Basile B. wrote:

 On Thursday, 19 August 2021 at 16:56:22 UTC, jmh530 wrote:

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

 [snip]

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


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


 smart evil


 to be honest:

 The situation is like we have now a feature nobody gives a shit 
 about.
 While type functions should have been something big and 
 interesting.

 I suspect that this feature nobody cares about was motivated by
 the newCTFE failure, which has caused a serious trusting issue 
 in Stefan work.

 I cannot be more honnest. This is really what I think.


and obviously I dont expect Walter Bright to answer: "yes you're 
right".
What kind of human being pubicly recognize their errors ?
Aug 19 2021
prev sibling parent reply Alexandru Ermicioi <alexandru.ermicioi gmail.com> writes:
On Thursday, 19 August 2021 at 20:16:19 UTC, Basile B. wrote:

 I suspect that this feature nobody cares about was motivated by
 the newCTFE failure, which has caused a serious trusting issue 
 in Stefan work.

 I cannot be more honnest. This is really what I think.


Tbh, the target of making a vm for compile time code was too high 
of a jump, hence epic crash. Before even attempting to do a vm 
for the compile time code, the compiler itself should've been in 
right state to be able to reuse existing components.

The target for new ctfe should've been something less grandiose, 
than full blown vm, and backend for it.

I really, anticipated that feature, since aedi (dependency 
injection lib) I've written relies on heavy template recursion 
and hence high compile time, and got really disappointed when 
nothing really came out of all advertising I've been seeing that 
time, really it should've been kept quiet, or as concise as 
possible instead of being loud all over forums.

R.I.P. (as far as I know) new ctfe on fancy vm.

Regards,
Alexandru.
Aug 19 2021
next sibling parent reply max haughton <maxhaton gmail.com> writes:
On Thursday, 19 August 2021 at 20:40:30 UTC, Alexandru Ermicioi 
wrote:

 On Thursday, 19 August 2021 at 20:16:19 UTC, Basile B. wrote:

 I suspect that this feature nobody cares about was motivated by
 the newCTFE failure, which has caused a serious trusting issue 
 in Stefan work.

 I cannot be more honnest. This is really what I think.


 Tbh, the target of making a vm for compile time code was too 
 high of a jump, hence epic crash. Before even attempting to do 
 a vm for the compile time code, the compiler itself should've 
 been in right state to be able to reuse existing components.

 The target for new ctfe should've been something less 
 grandiose, than full blown vm, and backend for it.

 I really, anticipated that feature, since aedi (dependency 
 injection lib) I've written relies on heavy template recursion 
 and hence high compile time, and got really disappointed when 
 nothing really came out of all advertising I've been seeing 
 that time, really it should've been kept quiet, or as concise 
 as possible instead of being loud all over forums.

 R.I.P. (as far as I know) new ctfe on fancy vm.

 Regards,
 Alexandru.


What other alternative is there? The existing interpreter is 
fundamentally slow, but there aren't many alternatives to roughly 
what Stefan was trying to do.

The issue is that parts of dmd are written with absolutely no 
concept of a big picture whatsoever and dependency resolution is 
done like a chimp let loose in an operating theatre. Writing 
something like newCTFE should not be that hard (You can write a 
bytecode interpreter in literally half a day, and translate an 
AST to that byte in another day - a week if you want test 
coverage), but as far as I can tell you end up with horrific 
problems because the "interpreter" is not an interpreter as per 
se but rather a glorified constant-folding step - i.e. things are 
still being resolved as the folding (all this wrapped in an awful 
interface, too! e.g. `null` can mean all kinds of things inside 
dmd - like not resolved, couldn't resolve, not present, haven't 
tried yet etc. in the same place) so what should be a simple task 
ends up going from balancing a stick to balancing an n-pendulum 
on your nose.

https://youtu.be/cyN-CRNrb3E

newCTFE also isn't dead, as far as I know it's blocked on 
something like exceptions - although I wouldn't call it exactly 
alive either. Some of that is Stefan's fault, some it is just 
fundamental to the problem. As for Stefan personally, he does get 
distracted and he should be much more complete in documenting 
what he is up to, but equally who else is doing anything else 
even remotely interesting? Since 2017 we've gained, what, static 
foreach? Innovation is hard, the state of our existing stuff 
isn't helping.

Simple guideline for future big (>10 commits) projects for D: 
They *must* be developed either in an official fork or in a 
branch in an official project, otherwise they'll wither and die 
without being seen by enough eyes.
Aug 19 2021
next sibling parent reply Adam Ruppe <destructionator gmail.com> writes:
On Thursday, 19 August 2021 at 21:01:14 UTC, max haughton wrote:

 Since 2017 we've gained, what, static foreach?


dmd -i came since then! And a few little things like more uda 
locations.

But dmd -i is by far the biggest thing in years. Pity its author 
got pushed out of further contributions by the broken process.
Aug 19 2021
parent reply Tejas <notrealemail gmail.com> writes:
On Thursday, 19 August 2021 at 21:21:33 UTC, Adam Ruppe wrote:

 On Thursday, 19 August 2021 at 21:01:14 UTC, max haughton wrote:

 Since 2017 we've gained, what, static foreach?


 dmd -i came since then! And a few little things like more uda 
 locations.

 But dmd -i is by far the biggest thing in years. Pity its 
 author got pushed out of further contributions by the broken 
 process.


We also got copy constructors, or is that not a big deal?

What happened to the contributor? Was it really bad procedure on 
our part?
Aug 19 2021
parent Adam Ruppe <destructionator gmail.com> writes:
On Friday, 20 August 2021 at 03:23:02 UTC, Tejas wrote:

 We also got copy constructors, or is that not a big deal?


I've never had a need for them and never used them, so totally 
irrelevant to me. I don't know if it is a big deal to other 
people.


 What happened to the contributor? Was it really bad procedure 
 on our part?


https://github.com/dlang/dmd/pull/7988

one of a few PRs that were closed after process arguments. He 
apparently works on the Zig language now.
Aug 20 2021
prev sibling parent reply Alexandru Ermicioi <alexandru.ermicioi gmail.com> writes:
On Thursday, 19 August 2021 at 21:01:14 UTC, max haughton wrote:

 What other alternative is there? The existing interpreter is 
 fundamentally slow, but there aren't many alternatives to 
 roughly what Stefan was trying to


I've always wondered, what was the problem to use ast as bytecode 
instead of actual bytecode. I.e. have an interpreter that puts 
the results on a stack, and all allocations done on a special 
region of heap, and then drop them as soon as the result is 
available, or is this how const folder/ctfe works now?


 The issue is that parts of dmd are written with absolutely no 
 concept of a big picture whatsoever and dependency resolution 
 is done like a chimp let loose in an operating theatre. Writing 
 something like newCTFE should not be that hard (You can write a 
 bytecode interpreter in literally half a day, and translate an 
 AST to that byte in another day - a week if you want test 
 coverage), but as far as I can tell you end up with horrific 
 problems because the "interpreter" is not an interpreter as per 
 se but rather a glorified constant-folding step - i.e. things 
 are still being resolved as the folding (all this wrapped in an 
 awful interface, too! e.g. `null` can mean all kinds of things 
 inside dmd - like not resolved, couldn't resolve, not present, 
 haven't tried yet etc. in the same place) so what should be a 
 simple task ends up going from balancing a stick to balancing 
 an n-pendulum on your nose.

 https://youtu.be/cyN-CRNrb3E


You're saying the exact thing I said, compiler isn't ready for a 
vm that works on bytecode. Also apparently a bytecode and vm for 
a simple calculator could be written in half day, not for a more 
complex language, per my observations of reports done during new 
ctfe development.


 newCTFE also isn't dead, as far as I know it's blocked on 
 something like exceptions - although I wouldn't call it exactly 
 alive either.


So it is a zombie. I hope at least some parts of this zombie 
could've been merged into dmd, not necessarily something that 
improves ctfe.


 but equally who else is doing anything else even remotely 
 interesting? Since 2017 we've gained, what, static foreach? 
 Innovation is hard, the state of our existing stuff isn't 
 helping.


Well that means that existing stuff needs to be improved so 
innovation can go, otherwise it would be the case that for a 
single change entire compiler would need to be modified (if going 
to edge).


 Simple guideline for future big (>10 commits) projects for D: 
 They *must* be developed either in an official fork or in a 
 branch in an official project, otherwise they'll wither and die 
 without being seen by enough eyes.


Or just by being public, and referenced on forums, so anyone can 
fork and contribute to it.

Regards,
Alexandru.
Aug 19 2021
parent reply bauss <jj_1337 live.dk> writes:
On Friday, 20 August 2021 at 06:33:13 UTC, Alexandru Ermicioi 
wrote:

 Or just by being public, and referenced on forums, so anyone 
 can fork and contribute to it.

 Regards,
 Alexandru.


This is the correct answer. I mean, the compiler is supposed to 
be open source and not multiple private sources that merges to a 
public repo.
Aug 20 2021
parent reply Alexandru Ermicioi <alexandru.ermicioi gmail.com> writes:
On Friday, 20 August 2021 at 10:39:42 UTC, bauss wrote:

 This is the correct answer. I mean, the compiler is supposed to 
 be open source and not multiple private sources that merges to 
 a public repo.


Tbh, it may have been shared (for newCtfe) I've just missed it. 
Please share the post if there is one.

Also, anyone knows how current ctfe is done?
Is it a stack based interpreter?

Thanks,
Alexandru
Aug 20 2021
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 21/08/2021 12:28 AM, Alexandru Ermicioi wrote:

 Tbh, it may have been shared (for newCtfe) I've just missed it. Please 
 share the post if there is one.


He linked it loads of times.

Current branch by the looks of it (so yeah, up to date).

https://github.com/UplinkCoder/dmd/tree/newCTFE_2093
Aug 20 2021
prev sibling parent max haughton <maxhaton gmail.com> writes:
On Friday, 20 August 2021 at 12:28:52 UTC, Alexandru Ermicioi 
wrote:

 On Friday, 20 August 2021 at 10:39:42 UTC, bauss wrote:

 This is the correct answer. I mean, the compiler is supposed 
 to be open source and not multiple private sources that merges 
 to a public repo.


 Tbh, it may have been shared (for newCtfe) I've just missed it. 
 Please share the post if there is one.

 Also, anyone knows how current ctfe is done?
 Is it a stack based interpreter?

 Thanks,
 Alexandru


It's a tree walker. It's not a very good tree walker, either, but 
the lack of locality is mostly why it's slow.
Aug 20 2021
prev sibling parent Basile B. <b2.temp gmx.com> writes:
On Thursday, 19 August 2021 at 20:40:30 UTC, Alexandru Ermicioi 
wrote:

 On Thursday, 19 August 2021 at 20:16:19 UTC, Basile B. wrote:

 I suspect that this feature nobody cares about was motivated by
 the newCTFE failure, which has caused a serious trusting issue 
 in Stefan work.

 I cannot be more honnest. This is really what I think.


 Tbh, the target of making a vm for compile time code was too 
 high of a jump, hence epic crash. Before even attempting to do 
 a vm for the compile time code, the compiler itself should've 
 been in right state to be able to reuse existing components.

 The target for new ctfe should've been something less 
 grandiose, than full blown vm, and backend for it.

 I really, anticipated that feature, since aedi (dependency 
 injection lib) I've written relies on heavy template recursion 
 and hence high compile time, and got really disappointed when 
 nothing really came out of all advertising I've been seeing 
 that time, really it should've been kept quiet, or as concise 
 as possible instead of being loud all over forums.

 R.I.P. (as far as I know) new ctfe on fancy vm.

 Regards,
 Alexandru.


What you say is moslty true, however there's a detail that you 
forget : it was also supposed to reduce memory use.

Anyway what I said yesterday, i reprhase because i was a bit 
"tired" let's say, is that I think that this failure had a 
negative impact on how type functions were perceived. newCTFE was 
sold to the community : many forum posts, several videos, a DConf 
talk, many hours spent to develop or to rebase...
So this was legit to be a bit doubtful when the same guy comes 
and say "new ctfe was BS, type functs is what we need"... but the 
answer to this doubt, so AliasAssign, was not great.
Aug 19 2021
prev sibling parent reply evilrat <evilrat666 gmail.com> writes:
On Thursday, 19 August 2021 at 06:23:52 UTC, surlymoor wrote:

 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](https://dlang.org/spec/declaration.html#AliasAssign).


OMG! What if we wanted extra safety to avoid redefining it, a 
`const alias`?
Aug 19 2021
parent Dukc <ajieskola gmail.com> writes:
On Thursday, 19 August 2021 at 15:42:27 UTC, evilrat wrote:

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


Use it for something right away and it will get locked. From the 
spec:


 The value of an AliasDeclaration or left hand side (lvalue) of 
 an AliasAssign may not be used prior to another AliasAssign to 
 the same lvalue other than in the right hand side of that 
 AliasAssign.
Aug 19 2021