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