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