On Friday, 12 February 2016 at 15:12:19 UTC, Steven Schveighoffer
wrote:
It could potentially differ based on the type being passed,
Yes, that's what I meant.
but I'm unaware of such an optimization,
Hm. Unfortunate.
and it definitely isn't triggered specifically by 'in'. 'in' is
literally replaced with 'scope const' when it is a storage
class.
Yeah, I didn't mean 'in' definitely triggered it. I meant that
'in' (or rather, as you say, 'scope const') provides the
conditions by which a compiler could make such an optimization,
since it can know that the parameter will be unaffected by the
function. It seems like that would mean it could, in theory,
choose to pass small objects by value and large objects by
reference under the hood, to avoid the large object copy
(assuming no custom post-blit...and I guess it would have to
check for taking the address?). To achieve that in C++ I use a
special trait which deduces whether pass-by-value or
pass-by-const-reference makes more sense for the type...but maybe
I should be doing the same thing in D, if that optimization isn't
actually present?
It does seem like the compiler could probably perform that
optimization even if 'in' (or 'scope const') wasn't used, if it
was smart enough...
This sort of micro-optimization generally doesn't matter at the
application level unless one has actually profiled it. But it
comes up a lot for me when writing generic libraries which can't
know whether it will be used in a situation someday where those
optimizations do actually matter.
