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’s even a preview? Did they change their minds or were some changes made?
>

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


Haha! Nice sleuthing.
Oh well, but late for that now...

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

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

>

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

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.

-Steve