`in` parameters made useful

IGotD- nise at nise.com
Thu Aug 20 17:31:17 UTC 2020

On Friday, 31 July 2020 at 21:49:25 UTC, Mathias LANG wrote:
> B) It makes `in` take the effect of `ref` when it makes sense. 
> It always pass something by `ref` if the type has elaborate 
> construction / destruction (postblit, copy constructor, 
> destructors). If the type doesn't have any of those it is only 
> passed by `ref` if it cannot be passed in register. Some types 
> (dynamic arrays, probably AA in the future) are not affected to 
> allow for covariance (more on that later). The heuristics there 
> still need some small improvements, e.g. w.r.t. floating points 
> (currently the heuristic is based on size, and not asking the 
> backend) and small struct slicing, but that should not affect 
> correctness.

This is interesting on a general level as well and true for 
several programming languages. Let the compiler optimize the 
parameter passing unless the programmer explicitly ask for a 
certain way (copy object, pointer/reference etc.). This is very 
unusual and if you have a language that optimizes the parameter 
passing by default, please mention it because it would be 

I'm all for that 'in' can be used for a "optimized const 
parameter" where the compiler optimizes as it wants. However, the 
question is if we want to override the default behaviour per 
object basis? As mentioned you might want to have another default 
behaviour for arrays but that can be true for other storage 
structures as well so this should really be user defined.

More information about the Digitalmars-d mailing list