On Thursday, 1 October 2020 at 18:29:14 UTC, Meta wrote:
On Thursday, 1 October 2020 at 17:29:56 UTC, Mathias LANG wrote:
On Thursday, 1 October 2020 at 16:47:37 UTC, Meta wrote:
[...]
Yes we have a 3rd way. Because `auto ref` just doesn't cut it
for most usages, and `-preview=rvaluerefparam` never worked.
You can have a look at the full discussion in the PR that
introduced it (dmd#11000).
I try to summarize a few arguments in favor of it here:
https://github.com/dlang/dmd/pull/11000#issuecomment-674498704
As you can see from the discussion, it's not really something
that was quickly merged, but the results of months of work. So
while it might seems "ridiculous" to you, I'd appreciate if
you could take the time to read through the discussion, as
well as taking a look at Herb Sutter's presentation which was
linked.
The key takeaway from that presentation is that instead of
having the users specify *how* to pass the parameter, they
should specify what is the parameter's semantic. In our case,
input (in), output (out), or input/output (ref).
I'm not aware of a situation where you want to use `auto ref`
on a parameter without `const` (or `const` semantic), because
if you intend to modify the parameter, you need to be sure
whether it's `ref` or not. I'm aware some people use it for
forwarding but this has its own set of problem.
I've read the discussion but skipped the presentation. All I
see is Atila expressing distaste for the compiler choosing how
to pass values, and no explicit sign-off from either Walter or
Atila before it was merged.
My objection is not to `in`'s new behaviour (although having
something that functions similarly to auto ref but in subtly
different ways is not good language design, IMO). My objection
is that we have a major change to a language feature, that was
merged without the apparent blessing of either of the two
people who are supposed to be the gatekeepers for these
decisions, and without a DIP (yes, it is behind -preview, but
that implies that this will eventually make it into the
language proper). That is what I am calling "ridiculous". If W
or A did approve it and I just wasn't aware, then I apologize
and retract my objection.
You seem to have a wrong understanding of -preview. It doesn't
even pretend to be an officially approved feature. I think this
is what's been causing the confusion.
Preview flags are what other compilers call "experimental". In
fact, -preview is intended to predate a DIP or formal approval in
other ways, because if you don't know the impact of a feature or
usefulness, it's very hard to make an informed decision.
This has the nice side effect that sometimes it becomes clear
during an implementation that the idea as is unfeasible.
implies that this will eventually make it into the language
proper
No, it doesn't.
