Performance improvements for D / DMD compiler.

[Dave]

Christian Kamm wrote:
> 
>>>  There's another aliasing case:
>>>  LargeStruct s;
>>> foo(s);
>>> ... here some other thread modifies s ...
> 
> Okay, I can see that this could result in unexpected behaviour. The idea 
> of determining whether to copy or not during compile time was not a good 
> one at all. What sparked this suggestion was exactly the situation Bill 
> Baxter described:
> 
>> The question is how can we write functions in D that take big structs 
>> as parameters in such a way that it is:
>> A) efficient and
>> B) guaranteed not to change the caller's value
> 
> If inout is used, it doesn't guarantee B) and even worse: I'm lying to 
> anyone reading the function signature. A pointer will also require 

I agree, I don't like the thought of us having to use inout as an optimization. That's not what it's 
meant for. Leaving aside the notion of 'const' right now, I think 'byref' or some such would work 
fine for this purpose. It tells a function user "this is passed by reference" and is easily 
grep-able (unlike '&').

And a pointer will require the use of '&' at every call site instead of 'byref' just once in the 
function definition.

> additional documentation to keep users from wondering whether their data 
> is changed or not. Making the struct a class is not an option because of 
> A).
> 
> Maybe it's just time to accept that D just doesn't do const the C++ way 
> and B) can't be expressed.
> 
> Christian