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
