C++Now! 2012 slides

[Artur Skawina]

On 06/07/12 20:19, Francois chabot wrote:
> On Thursday, 7 June 2012 at 17:17:07 UTC, Artur Skawina wrote:
>> On 06/07/12 18:04, bearophile wrote:
>>> Page 46: #pragma no_alias Are we going to need something like that (or "restrict") in D too?
>>
>> "restrict" functionality - yes, but it's probably better done the other way around -
>> restrict as default and "alias" when necessary. Reusing the keyword could work too,
>> if template parameters is the only thing that can clash.
> 
> For this to work, the compiler would need to accurately imply aliasing with a 100% accuracy, to spit out errors. And if that was possible we would not need programmers hints at all. With restrict as a keyword, at least the programmer is aware of how "dangerous" that code is.

Yes, it can't (always) be statically checked. But the alternative is restrict
proliferation; it applies not only to pointers, but also to slices. Hence defining
the language in a way that reduces the need for extra annotations would be best.
I'm not sure if that can be done safely for at least some subset of cases (function
arguments, mostly), that's why I said "probably" above. But it is something that
should be explored before blindly transplanting "restricted" to D.
While static compile-time checks aren't always possible, the rest could in theory
be handled by run-time checks in non-release mode. I'm not sure it would be enough.
A way to explicitly tag things as not aliasing anything else would also be handy;
'restricted' would work for that, maybe even 'uniq' could be overloaded and help.
This is eg for pointers extracted from some data structures, which are known to
not alias any others of the same kind present the current scope.

artur