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

[Jonathan M Davis]

On Friday, May 04, 2018 09:15:57 Vijay Nayar via Digitalmars-d wrote:
> While working on a library built for high efficiency, avoiding
> unnecessary copies of structs became an issue.  I had assumed
> that `in` was doing this, but a bit of experimentation revealed
> that it does not.  However, `ref in` works great.
>
> My question is, should `in` by default also imply `ref` for value
> types like structs?  Is there a reason not to do this?

ref only accepts lvalues and as such can be extremely annoying to use.
There's no question that it has its place, but in most cases, you don't want
it, because it makes it so that you then mostly can't chain function calls
and are forced to store all of the function results on the stack in order to
call the next function. And addition to being annoying, it's usually less
less efficient, because if you pass an rvalue to a function, then the value
is moved to the parameter, which can't be done if you store the value on the
stack. 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.

So, even if we were designing in from scratch, making ref would be a
questionable choice. However, even if we all agreed that it would be
desirable, such a change would break a large percentage of code that
currently uses in, because any code that passes an rvalue to a function
taking its argument as in would then break. So, any attempt to change in to
include ref would have to have some sort of deprecation path to avoid code
breakage. But given how annoying it would be to have in be ref by default
due to how that affects rvalues, I'm willing to bet that most programmers
would not be at all happy with such a change, regardless of how well the
transitition was handled.

- Jonathan M Davis