About ref used for performance reasons with struct

[Maxim Fomin]

On Monday, 11 February 2013 at 06:52:33 UTC, deadalnix wrote:
> Ok, We have 2 usages of ref : when you actually need to modify 
> informations, and for performance reasons. Let's talk about the 
> second one.
>
> Passing by ref to improve performance is not ideal. First this 
> is quite hard to know when it is actually faster to pass by ref 
> and to pass by value, especially in generic code. Secondly it 
> is easy to forget to use ref at some location, and a lot of 
> small performance improvement are lost in the process. Finally, 
> this may be error prone.
>
> I'm thinking about it for a while now and I'm now convinced 
> that we should allow the compiler to do that job for us. Let me 
> explain.
>
> When a function accept a struct, the compiler is free to use 
> that function, or an altered one taking a reference as 
> parameter. Here are some rules the compiler can use to know 
> which one to call from callee side :

I expect this to be a nightmare for both users, who would 
experience new pile of struct bugs and for developers. How much 
code would this proposal break?

What do you mean by 'altered'? Are you taking about two function 
versions or a single one? If first, how does it work with 
linking, and if second, how does it work for different 
situations? What happens when you use function pointer or a 
delegate? How __traits works with respect to function type in 
case of such optimization? What happens if compiler cannot deduce 
from context information required to make such decision? How does 
it play with variardic functions? And how such optimization can 
be disabled?