Performance improvements for D / DMD compiler.

[Dave]

Bill Baxter wrote:
> Dave wrote:
>> Christian Kamm wrote:
>>> 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.
> 
> So you're suggesting byref would be a synonym for inout?  And the 
> compiler would treat it exactly like the current inout?  If the 
> compiler's not going to be of any help in making sure that I don't 
> change things that I don't mean to be changing, then I don't see much 
> point in introducing a new keyword.
> 

'inout' doesn't necessarily specify 'byref'. But, in C++ if you specify '&' then the param. must be 
passed by reference. 'byref' would act like that. 'byref' doesn't have to satisfy the IDL 
requirement like inout does either.

I agree that if it could be made to work, 'byref' acting like a semantically meaningful C++ 'const&' 
would be great (then  maybe 'cref' for the keyword?).

D is terrific - truly a better C++ while avoiding almost all of C++'s corner cases. But IMHO D takes 
this a little too far without reference params. and being able to return references (and ctors for 
structs while I'm at it). They are used so often in C++ I find it hard to justify a language design 
for 'a better C++' that doesn't match those capabilities.

> --bb