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.
