Things that keep D from evolving?

[Matt Elkins via Digitalmars-d-learn]

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.