Passing an in parameter and aliasing

[Bill Baxter]

Oskar Linde wrote:
> Bill Baxter skrev:
>> Dave wrote:
>>> [restrict]
>> That's C's philosophy anyway.  And I haven't heard anything from 
>> Walter that sounded to me like D was taking a different approach.  I 
>> think a 'restrict' type keyword probably is the best way to handle it 
>> in a C-like language.  Most code doesn't need the performance boost as 
>> much as it needs predictability and reliability.  Aliasing bugs can 
>> also be very tricky to debug because things might work great on your 
>> computer but only fail on some other machine when compiled with SSE3 
>> instructions and -03 optimizations.  So it makes sense for performance 
>> critical code to declare in a visible way that it's placing some 
>> restrictions on the kind of inputs that will work.
>>
>> So I think D could still use a separate restrict-like keyword.  But I 
>> think it could be made a little more user friendly than C's by 
>> allowing it to apply to a whole function rather than having to say 
>> 'restrict' 'restrict' 'restrict' for every single parameter.
> 
> Here is an old thread about "noalias, restrict, and Fortran optimizations":
> 
> http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=D&artnum=28215&header 

Thanks for that.  Here's a few follow-up posts I found ... that news 
interfaces doesn't seem to have a "threaded" view, so finding the rest 
of the thread isn't easy.

http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=D&artnum=28236
http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=D&artnum=28372
http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=D&artnum=28377
http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=D&artnum=28379

Last thing I see from Walter is musing about making everything noalias 
with a way to turn that off.  My problem with that is most code doesn't 
need it, and it would be confusing for users not expecting it to find 
out that a[i] = b[i] - c[i]; doesn't always execute exactly as 
a[i]=b[i]-c[i].    Walter's right that the vast majority of code doesn't 
rely on C-like non-restrict behavior.  But I'd counter that the vast 
majority of code also doesn't need it.  Better to put something 
potentially dangerous as an option usable by people who know what 
they're doing rather than making it the default.

Anyway, generating optimized code is probably at least 2 years away from 
being anywhere near a priority for Walter.  :-)  [he says hoping he 
turns out to be wrong]

--bb