Can we enable -preview=rvaluereference now?

[Quirin Schroll]

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

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.

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