🚀 go-pugleaf

tanmoy@qcd.lanl.gov (Tanmoy Bhattacharya) wrote:
[snip]
>By the way, does this mean that that after
>
>int f(const int);
>int g(const int);
>int g(const int);
>
>f has type int(const int) because types do not need to be composed: there is
>only one declaration, but g has type int(int)? Maybe, but it does not have
>any observable effects yet. However such curiosities bother me because
>some simple change in the standard can someday make this clearly
>unintended difference observable; and that I cannot think of what that
>dangerous change is, should be no reason to not fix this. This probably ought
>to be corrected by stating that the parameter qualifiers are never a part of
>the function type.

I agree, this could use some clarification.

>The TC1 statement clearly shows (in its use of `In the determination of
>type compatibility and of composite type' as a qualifier) that the type of a
>parameter and the `type of the parameter in the prototype part of the
>function type' need not be the same.

Okay, I see the subtle distinction. The parameters in a function type's
parameter type list can be differently qualified (and therefore of a different
type because qualified types are distinct) than the types of the corresponding
parameters themselves. This can only occur if the function type is constructed
as a composite type of two function types with parameter type lists. Spooky.

-- 
Paul Long                               45:29:14N 122:48:09W
plong@perf.com                          http://www.teleport.com/~pciwww/
    "Where time or intelligence are lacking, a goto may do the job."
        - M.E. Hopkins, "A Case for the GOTO," 1972.