Passing an in parameter and aliasing

[Dave]

Bill Baxter wrote:
> renoX wrote:
>> Bill Baxter a écrit :
> 
>>> The thing with this is it may catch the error but it doesn't help the 
>>> compiler generate more optimized code.  The C99 'restrict' keyword 
>>> does, though.  I suppose the compiler could be smart enough to deduce 
>>> 'restrict' semantics are in effect from the assert message above.  
>>> That would be pretty neat.
>>
>> Well, if I understood correctly Jarrett Billingsley's answer, the 
>> semantic on 'in' is the same as 'restrict': the fastest as the 
>> compiler will be free to optimize but the most fragile from 
>> programmers point of view because if you violate the restrict 
>> restriction the result is unpredictable (no bug, a bug depending on 
>> optimization flags, fun!)
>>
>> Sure, it'd be nice if the compiler was able to do this kind of 
>> optimization without the in|restrict hint but this is hard.
> 
> The 'in' parameter type does nothing currently.  Leaving it off is the 
> same as putting it in.  So I don't believe it acts like 'restrict'.  I 

That's right (verifiable through the asm).

> certainly don't remember reading anywhere in the spec that D assumes all 
> 'in' array parameters are unaliased.  That would be a big break from 
> C/C++ if it were so, so I think the spec would go out of its way to 
> point out the difference.
> 

I believe that's part of the overall justification for the new for 2.0 'in', which will mean 'scope 
const final' for any type of reference parameter (correct me if I'm wrong Walter). Then the 
optimizer will be free to do its thing with those references, w/o any complicated pointer analysis 
or runtime checking.

IIUC, the compiler front-end will do it's best to enforce it (unlike C's 'restrict') and I believe 
it won't be as easy to cast away like C++'s 'const&'.

If so that'd be pretty cool, because it would make D competitive with Fortran in this regard.

Toward the end of the thread on this over in d.D.announce, it looks like 'in' will be the default 
parameter (so 'foo(int[] array){}' would be the same as 'foo(in int[] array){}'). I'm hoping that's 
the case -- at least given a try first for 2.0 anyway.

> --bb