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