digitalmars.D - Can we enable -preview=rvaluereference now?
- Manu (9/9) Aug 12 So this preview has been available for more than 5 years.
- Daniel N (2/15) Aug 12 yes, please!
- ryuukk_ (3/16) Aug 12 I have it enabled on all my projects
- Nicholas Wilson (2/4) Aug 13 https://github.com/dlang/dmd/pull/16778
- Nicholas Wilson (6/10) Aug 13 at the moment, no because it doesn't pass CI. Templates with `ref
- cc (5/18) Aug 14 Where can I find the spec/explanation/DIP for
- Manu (4/23) Aug 14 That's my first attempt... then Andrei gave a keynote advocating it
- Quirin Schroll (8/21) Aug 16 Can we please remove it? It's a silent breaking change as it
- Manu (15/37) Aug 16 Remove it? What harm has it caused you?
- Steven Schveighoffer (5/21) Aug 16 Keep in mind that everyone has been using rvalue references with
- Quirin Schroll (27/73) Aug 19 This isn’t a criminal court where I have to prove having suffered
So this preview has been available for more than 5 years. Andrei did a keynote on it, and that seemed generally well received (if not a little tepid, because not so many people care about this). All the code I've written in the last 5 years doesn't work without this. I have exercised this pretty extensively in whatever flavour of code it is that I tend to write, and never had any problem. It works like it's meant to. I would severely struggle to return to a D without it. Can we un-preview this now?
Aug 12
Daniel N <no public.email> On Tuesday, 13 August 2024 at 04:23:15 UTC, Manu wrote:So this preview has been available for more than 5 years. Andrei did a keynote on it, and that seemed generally well received (if not a little tepid, because not so many people care about this). All the code I've written in the last 5 years doesn't work without this. I have exercised this pretty extensively in whatever flavour of code it is that I tend to write, and never had any problem. It works like it's meant to. I would severely struggle to return to a D without it. Can we un-preview this now?yes, please!
Aug 12
On Tuesday, 13 August 2024 at 04:23:15 UTC, Manu wrote:So this preview has been available for more than 5 years. Andrei did a keynote on it, and that seemed generally well received (if not a little tepid, because not so many people care about this). All the code I've written in the last 5 years doesn't work without this. I have exercised this pretty extensively in whatever flavour of code it is that I tend to write, and never had any problem. It works like it's meant to. I would severely struggle to return to a D without it. Can we un-preview this now?I have it enabled on all my projects +1
Aug 12
On Tuesday, 13 August 2024 at 04:23:15 UTC, Manu wrote:So this preview has been available for more than 5 years. Can we un-preview this now?https://github.com/dlang/dmd/pull/16778
Aug 13
On Tuesday, 13 August 2024 at 09:11:22 UTC, Nicholas Wilson wrote:On Tuesday, 13 August 2024 at 04:23:15 UTC, Manu wrote:at the moment, no because it doesn't pass CI. Templates with `ref T` with `T==void` (misrecognised untyped lambdas e.g. `str => dst.put(str)` which should be a delegate) give e.g.: std/bigint.d(1280): Error: cannot have parameter of type `void`So this preview has been available for more than 5 years. Can we un-preview this now?https://github.com/dlang/dmd/pull/16778
Aug 13
Are our previews not tested for compatibility? It kinda feels like preview features should surely get tested, such that we know the preview represents a valid feature... On Tue, 13 Aug 2024 at 20:46, Nicholas Wilson via Digitalmars-d < digitalmars-d puremagic.com> wrote:On Tuesday, 13 August 2024 at 09:11:22 UTC, Nicholas Wilson wrote:On Tuesday, 13 August 2024 at 04:23:15 UTC, Manu wrote:at the moment, no because it doesn't pass CI. Templates with `ref T` with `T==void` (misrecognised untyped lambdas e.g. `str => dst.put(str)` which should be a delegate) give e.g.: std/bigint.d(1280): Error: cannot have parameter of type `void`So this preview has been available for more than 5 years. Can we un-preview this now?https://github.com/dlang/dmd/pull/16778
Aug 14
On Tuesday, 13 August 2024 at 10:43:18 UTC, Nicholas Wilson wrote:On Tuesday, 13 August 2024 at 09:11:22 UTC, Nicholas Wilson wrote:That’s feels like the silliest reason to not un-preview something, and I bet if we just did it anyway then someone would actually fix that.On Tuesday, 13 August 2024 at 04:23:15 UTC, Manu wrote:at the moment, no because it doesn't pass CI. Templates with `ref T` with `T==void` (misrecognised untyped lambdas e.g. `str => dst.put(str)` which should be a delegate) give e.g.: std/bigint.d(1280): Error: cannot have parameter of type `void`So this preview has been available for more than 5 years. Can we un-preview this now?https://github.com/dlang/dmd/pull/16778
Aug 14
On Thu, 15 Aug 2024 at 01:41, IchorDev via Digitalmars-d < digitalmars-d puremagic.com> wrote:On Tuesday, 13 August 2024 at 10:43:18 UTC, Nicholas Wilson wrote:I'm pretty sure Nick is in support of un-preview-ing it. That's just the state of it...On Tuesday, 13 August 2024 at 09:11:22 UTC, Nicholas Wilson wrote:That=E2=80=99s feels like the silliest reason to not un-preview something, and I bet if we just did it anyway then someone would actually fix that.On Tuesday, 13 August 2024 at 04:23:15 UTC, Manu wrote:at the moment, no because it doesn't pass CI. Templates with `ref T` with `T=3D=3Dvoid` (misrecognised untyped lambdas e.g. `str =3D> dst.put(str)` which should be a delegate) give e.g.: std/bigint.d(1280): Error: cannot have parameter of type `void`So this preview has been available for more than 5 years. Can we un-preview this now?https://github.com/dlang/dmd/pull/16778
Aug 14
On Wednesday, 14 August 2024 at 23:50:51 UTC, Manu wrote:I'm pretty sure Nick is in support of un-preview-ing it. That's just the state of it...Given that the language maintainers rejected the DIP, how come there’s even a preview? Did they change their minds or were some changes made?
Aug 15
This implementation isn't the result of my DIP. Andrei's proposal was somehow different than mine, and it was approved and promptly implemented. I don't remember any more details than that (I don't really care), but I'm sure someone does! It all happened pretty quick in 2019 (to my surprise!)... you kinda had to be there :P On Thu, 15 Aug 2024 at 18:56, IchorDev via Digitalmars-d < digitalmars-d puremagic.com> wrote:On Wednesday, 14 August 2024 at 23:50:51 UTC, Manu wrote:I'm pretty sure Nick is in support of un-preview-ing it. That's just the state of it...Given that the language maintainers rejected the DIP, how come there=E2=80=99s even a preview? Did they change their minds or were some changes made?
Aug 15
On Thursday, 15 August 2024 at 13:12:27 UTC, Manu wrote:and it was approved and promptly implemented.The DIP wasn't approved. It wasn't finished and never even entered the draft review stage. It's a GitHub gist: https://gist.github.com/andralex/e5405a5d773f07f73196c05f8339435a And was implemented under the guise of:Although the DIP isn't finished yet, we can try out the ideas.https://github.com/dlang/dmd/pull/9817
Aug 15
On Thu, 15 Aug 2024 at 23:37, Dennis via Digitalmars-d < digitalmars-d puremagic.com> wrote:On Thursday, 15 August 2024 at 13:12:27 UTC, Manu wrote:Haha! Nice sleuthing. Oh well, but late for that now...and it was approved and promptly implemented.The DIP wasn't approved. It wasn't finished and never even entered the draft review stage. It's a GitHub gist: https://gist.github.com/andralex/e5405a5d773f07f73196c05f8339435a And was implemented under the guise of:Although the DIP isn't finished yet, we can try out the ideas.https://github.com/dlang/dmd/pull/9817
Aug 15
On Tuesday, 13 August 2024 at 04:23:15 UTC, Manu wrote:So this preview has been available for more than 5 years. Andrei did a keynote on it, and that seemed generally well received (if not a little tepid, because not so many people care about this). All the code I've written in the last 5 years doesn't work without this. I have exercised this pretty extensively in whatever flavour of code it is that I tend to write, and never had any problem. It works like it's meant to. I would severely struggle to return to a D without it. Can we un-preview this now?Where can I find the spec/explanation/DIP for -preview=rvaluereference? Is it different from https://github.com/dlang/DIPs/blob/master/DIPs/rejected/DIP1016.md ?
Aug 14
On Thu, 15 Aug 2024 at 00:32, cc via Digitalmars-d < digitalmars-d puremagic.com> wrote:On Tuesday, 13 August 2024 at 04:23:15 UTC, Manu wrote:That's my first attempt... then Andrei gave a keynote advocating it (2019?), and it was promptly implemented under this preview flag.So this preview has been available for more than 5 years. Andrei did a keynote on it, and that seemed generally well received (if not a little tepid, because not so many people care about this). All the code I've written in the last 5 years doesn't work without this. I have exercised this pretty extensively in whatever flavour of code it is that I tend to write, and never had any problem. It works like it's meant to. I would severely struggle to return to a D without it. Can we un-preview this now?Where can I find the spec/explanation/DIP for -preview=rvaluereference? Is it different from https://github.com/dlang/DIPs/blob/master/DIPs/rejected/DIP1016.md ?
Aug 14
On Tuesday, 13 August 2024 at 04:23:15 UTC, Manu wrote:So this preview has been available for more than 5 years. Andrei did a keynote on it, and that seemed generally well received (if not a little tepid, because not so many people care about this). All the code I've written in the last 5 years doesn't work without this. I have exercised this pretty extensively in whatever flavour of code it is that I tend to write, and never had any problem. It works like it's meant to. I would severely struggle to return to a D without it. Can we un-preview this now?Can we please remove it? It's a silent breaking change as it changes the semantics of every function that has `ref` parameters with the implicit or explicit understanding that it can't take rvalues. Add ` universal ref`. It's a pure addition and wouldn't break code. Manu and others could just search and replace `ref` by ` universal ref` and be happy. Changing `ref` to make it take rvalues never was a good idea.
Aug 16
On Sat, 17 Aug 2024, 09:36 Quirin Schroll via Digitalmars-d, < digitalmars-d puremagic.com> wrote:On Tuesday, 13 August 2024 at 04:23:15 UTC, Manu wrote:Remove it? What harm has it caused you? You'll need to substantiate these claims? You're wrong on all accounts by my experience and reckoning. I've been using it for 5 years and all my code would fail without it, several others at the top of this thread also said the same thing. I have never experienced an issue or anything related to it that caused something like "silent breakage". I exercise the language pretty intensely, more so than most. I think you need to present a rock solid case to invalidate half a decade of several people's work, and you'll have to do better then "I don't care for that in theory", or "the idea kind-of makes me nervous despite never having turned the flag on and having literally no experience with it one way or the other"...So this preview has been available for more than 5 years. Andrei did a keynote on it, and that seemed generally well received (if not a little tepid, because not so many people care about this). All the code I've written in the last 5 years doesn't work without this. I have exercised this pretty extensively in whatever flavour of code it is that I tend to write, and never had any problem. It works like it's meant to. I would severely struggle to return to a D without it. Can we un-preview this now?Can we please remove it? It's a silent breaking change as it changes the semantics of every function that has `ref` parameters with the implicit or explicit understanding that it can't take rvalues. Add ` universal ref`. It's a pure addition and wouldn't break code. Manu and others could just search and replace `ref` by ` universal ref` and be happy. Changing `ref` to make it take rvalues never was a good idea.
Aug 16
On Saturday, 17 August 2024 at 00:11:35 UTC, Manu wrote:On Sat, 17 Aug 2024, 09:36 Quirin Schroll via Digitalmars-d, < digitalmars-d puremagic.com> wrote:Keep in mind that everyone has been using rvalue references with struct member functions forever, with very few complaints. This is what convinced me that it's fine. -SteveCan we please remove it? It's a silent breaking change as it changes the semantics of every function that has `ref` parameters with the implicit or explicit understanding that it can't take rvalues. Add ` universal ref`. It's a pure addition and wouldn't break code. Manu and others could just search and replace `ref` by ` universal ref` and be happy. Changing `ref` to make it take rvalues never was a good idea.I think you need to present a rock solid case to invalidate half a decade of several people's work, and you'll have to do better then "I don't care for that in theory", or "the idea kind-of makes me nervous despite never having turned the flag on and having literally no experience with it one way or the other"...
Aug 16
On Saturday, 17 August 2024 at 00:11:35 UTC, Manu wrote:On Sat, 17 Aug 2024, 09:36 Quirin Schroll via Digitalmars-d, < digitalmars-d puremagic.com> wrote:This isn’t a criminal court where I have to prove having suffered harm to myself to have standing. As a preview, it requires opting-in. Not many did, I presume.On Tuesday, 13 August 2024 at 04:23:15 UTC, Manu wrote:Remove it? What harm has it caused you?So this preview has been available for more than 5 years. Andrei did a keynote on it, and that seemed generally well received (if not a little tepid, because not so many people care about this). All the code I've written in the last 5 years doesn't work without this. I have exercised this pretty extensively in whatever flavour of code it is that I tend to write, and never had any problem. It works like it's meant to. I would severely struggle to return to a D without it. Can we un-preview this now?Can we please remove it? It's a silent breaking change as it changes the semantics of every function that has `ref` parameters with the implicit or explicit understanding that it can't take rvalues. Add ` universal ref`. It's a pure addition and wouldn't break code. Manu and others could just search and replace `ref` by ` universal ref` and be happy. Changing `ref` to make it take rvalues never was a good idea.You'll need to substantiate these claims? You're wrong on all accounts by my experience and reckoning.As you write it, your experience is with writing code with the preview flag in mind. That means the implementation probably has no obvious major bugs.I've been using it for 5 years and all my code would fail without it, several others at the top of this thread also said the same thing. I have never experienced an issue or anything related to it that caused something like "silent breakage". I exercise the language pretty intensely, more so than most.Some function calls change from being invalid to being valid. Normally, breakage of some `__traits(compiles)` or `is(typeof())` isn’t considered relevant breakage, but if a function can be called using an rvalue, some introspection code using `is(typeof(f(rvalueOf!T)))` to test something will make a wrong (or at least: unexpected) decision. My sense is that a lot of D code was written with the (implicit) assumption in mind that `ref` only binds lvalues. You don’t have any recourse for people who rely on that. They can’t tag the `ref` as lvalue-only. And while overloading with a ` disable`d pass-by-copy version is theoretically an option, there can can be issues with that, too, as e.g. an overloaded function can’t have its address taken as easily. I’m giving you that in ` safe` code, probably some people get compile errors that are easy to fix. In ` system` code, however, it could introduce weird bugs, and it is hard to say how likely that is.I think you need to present a rock solid case to invalidate half a decade of several people's work, and you'll have to do better then "I don't care for that in theory", or "the idea kind-of makes me nervous despite never having turned the flag on and having literally no experience with it one way or the other"...I think you need a rock solid argument for changing behavior of a widely-used language construct over an alternative that is a pure addition.
Aug 19
On Monday, 19 August 2024 at 12:58:15 UTC, Quirin Schroll wrote:Do you have any code or know of any code that actually relies on `ref` parameters being lvalues? Also, if you really want lvalues just make your parameter a pointer or something.I think you need to present a rock solid case to invalidate half a decade of several people's work, and you'll have to do better then "I don't care for that in theory", or "the idea kind-of makes me nervous despite never having turned the flag on and having literally no experience with it one way or the other"...I think you need a rock solid argument for changing behavior of a widely-used language construct over an alternative that is a pure addition.
Aug 19
On Monday, 19 August 2024 at 12:58:15 UTC, Quirin Schroll wrote:I think you need a rock solid argument for changing behavior of a widely-used language construct over an alternative that is a pure addition.Just for reference, I have `-preview=rvaluerefparam` in all my build scripts from day one it was introduced. Juraj
Aug 20
On Tuesday, 20 August 2024 at 09:50:41 UTC, Juraj wrote:On Monday, 19 August 2024 at 12:58:15 UTC, Quirin Schroll wrote:Honestly I didn’t know about it, otherwise I would’ve been using it the whole time.I think you need a rock solid argument for changing behavior of a widely-used language construct over an alternative that is a pure addition.Just for reference, I have `-preview=rvaluerefparam` in all my build scripts from day one it was introduced. Juraj
Aug 20