(breaking change) self vs &self and non-copy scalars

[nical]

(breaking change) self vs &self and non-copy scalars

[nical]

Looks like we are on the same page. Just wanted to enumerate options and test the water before writing all the code.

[nical]

cc @kvark

[kvark]

This would mean the question of &self vs self would not impact the user

If we consider the scope of the issue to be larger than self, i.e. when do we pass by value versus by reference, than this will still impact the users.

[nical]

Sorry my phrasing was a bit clumsy. I do think we should keep the current rule about what we pass by ref and by value for non-self parameters. I believe it works well and changing it would require updating so much code that we'd want a really strong motivation. So I'm referring only to the self parameter.

What I meant was that for non-copyable types it matters a great deal whether or not the methods consumes self, whereas if every vector is Copy no matter what, &self vs self is still a breaking change but not something that would limit or increase the expressiveness of the API or make much of a difference in how the API is used (I think).

[kvark]

I'd prefer the API to just be consistent with regards to references. We shouldn't make an exception for self.
Otherwise, what would your guideline be? "if it's less than 16 bytes, pass by value, unless it's self parameter, and type doesn't implement Copy, and a lot of user code doesn't want to clone"?
Can we just say that all the types that our guideline requires to be passed by value would implement Copy. That would mean we are never in a situation where the user needs to do something.clone().foo(...).