Bill Homer wrote:
> Nevertheless, I think we agree that the real problem is devising some
> congenial syntactic means of specifying restricted_copy as a
> specialization of the generic copy.
Right on!
> If a restrict qualifier at the
> top level in a type follows the same rules as const and volatile
> (which I think it should)
My gut feeling is that it should not. Const and volatile after an
asterisk talk about the pointer itself (the place where its value is
stored), not about the pointer's target. The top-level qualifiers that
exist so far (const and volatile) do not affect overloading
because they do not make a semantic difference for a caller (the caller
shouldn't care whether the implementation modifies the pointer's value
or not).
In contrast to this, restrict talks about the target, not really about
the pointer's value. Therefore, it does make a semantic difference
to the caller (the caller *must* care whether pointer targets are
aliased or not). Consequently restrict should participate in overloading.
In this sense, restrict is not a top-level qualifier.
Admittedly, restrict syntactically behaves somewhat like a top level
qualifier. As far as I understand it, restrict was `syntactically
moved behind the asterisk or ampersand' to indicate that it can only
be used on pointers and references (and to keep the syntax simple).
Maybe the keyword conceptually belongs
before the asterisk (e.g. copy(int const restrict *, int *)).
There are places where const can be used where restrict is not
allowed. For other places, the converse is true (`&restrict' is OK,
`&const' is bogus). So it should be no big problem to also differentiate
them with respect to overloading. The language spec may be uglier then,
but it will be more useful.
I would like to read about the reasoning behind restrict in C, can
anybody point me to a reference about this?
Rainer
--------------------- Object Oriented Numerics List --------------------------
* To subscribe/unsubscribe: use the handy web form at
http://oonumerics.org/oon/
* If this doesn't work, please send a note to owner-oon-list@oonumerics.org
This archive was generated by hypermail 2b29 : Wed Feb 20 2002 - 03:20:12 EST