Should 'in' Imply 'ref' as Well for Value Types?

[Jonathan M Davis]

On Sunday, May 06, 2018 21:26:32 Q. Schroll via Digitalmars-d wrote:
> On Saturday, 5 May 2018 at 15:39:19 UTC, Jonathan M Davis wrote:
> > On Saturday, May 05, 2018 15:22:04 Bolpat via Digitalmars-d
> >
> > wrote:
> >> On Friday, 4 May 2018 at 09:34:14 UTC, Jonathan M Davis wrote:
> >> > [...]
> >> > It's actually not infrequent now that in C++, you want to
> >> > pass
> >> > stuf by value rather than const& precisely because move
> >> > semantics can be used to avoid copies. So, it's not at all
> >> > necessarily the case that passing by ref is the efficient
> >> > thing
> >> > to do. It's heavily dependent on the code in question.
> >>
> >> I once proposed that `in` can mean `const scope ref` that also
> >> binds rvalues.
> >> https://github.com/dlang/DIPs/pull/111#issuecomment-381911140
> >> We could make `in` be something similar to `inline`. The
> >> compiler
> >> can implement it as stated above (assign the expression to
> >> temporary, reference it), or use copy if copy is cheaper than
> >> referencing.
> >
> > Having ref of any kind accept rvalues is a highly controversial
> > issue, and it may or may not ever be in the language. If it's
> > added, then at that point, whether it makes sense to make in
> > imply ref could be re-examined, and maybe at that point, doing
> > so would make great sense. But as long as ref does not accept
> > rvalues, it really doesn't make sense. It would break too much
> > code and would be far too annoying to use in many, many cases
> > where it is currently commonly used.
>
> I never suggested some spelled out `ref` should bind rvalues.
> Having explicit `ref` bind rvalues is a mistake C++ did and it
> confuses the hell out of people.
>
> For clarification:
> `in` should mean for the called function that it may only "look
> at" the information for decisions, but not "touch" it. In this
> sense, not only modifying, also copying or leaking it are a forms
> of touching. Note that objects of a non-copyable types can be
> looked at.
> This is how I came to what `in` naturally must mean.
> It must mean `const`. It must mean `scope`. It must mean
> referencing, but not in the restrictive way of `ref`, but in the
> permissive interpretation, so it may bind rvalues, too.
> For the caller, `in` basically is `const scope` with guaranteed
> no copying.
>
> So, `in` should not imply `ref`, it should imply referencing,
> which is not the same thing.
> `in` and `ref` could be combined, so that the restrictive
> character of `ref` does its job, but I'd favor not to allow that
> (similarly `out ref` is not allowed). If you want `const scope
> ref`, spell it out. I'd assume the cases where you want to allow
> lvalues only are rare. They well may exist, so it's good to be
> able to express them.

in has always copied if it was not also used with ref, and changing that
would break code. It's also never actually really meant scope, much as that
was the intention (mostly because aside from delegates, scope has never done
anything). -dip1000 is finally doing something with scope, but in the
process, it looks likely that in will then not mean scope due to the amount
of code that would break if it did, but we'll have to see how that goes.
Historically though, in has been pretty much identical to const.

Regardless, you seem to be describing something that has nothing to do with
how any type qualifier or storage class currently acts. If you want to
anything like that, you're going to have to create a DIP for it, and if
you're looking for in to mean anything drastically different like it seems
like you want to, you're going to have to present good arguments for why
such a change would make good sense, what the resulting code breakage would
be, and why it would be worth it. And honestly, much as you say that you
don't want to have ref bind rvalues, what you're saying sounds a lot like
you're arguing for an equivalent to const& with the addition that it's also
scope, and Andrei has repeatedly shot down anything similar to C++'s const&.
So, you'll need solid arguments for why what you want is a good idea.

- Jonathan M Davis