`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
interesting.
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