Re: Prefix attributes vs. grammar

[Mark Mitchell <mark at codesourcery dot com>]

> If "mode" isn't treated specially, ill-formed, no diagnostic required,
> same as violations of the one definition rule across translation units.

This is plausible, but not necessarily what people want or expect.
Analogy with the ODR is sort-of reasonable, sort-of not; the ODR is
what is supposed to get you if you change the definition of a template
function in different translation uses; to have two "same" instantiations
of the same template yield different bodies is a new and different
problem for people to deal with.

I would actually have preferred that you said "ill-formed, diagnostic
required", i.e., that argument types to templates may not be attributed.
That way, we would admit that we don't really know what this means,
and then people would be prevented from relying on the behavior-du-jour.
In general, if we must introduce a new language feature without figuring
out exactly how it interacts with everything else, I think we should 
explicitly prevent it from interacting with other things.  But, there
are so many places, in this case, that I have no idea if we could
actually have done that.

Related questions include what `typeid' returns for an attributed type.
If it is the same as the non-attributed variant, then we have the
case that two typeids will be the same for types that the compiler
does not think are the same; if it returns a different typeid then
we have to do more work than we are currently doing.

How do conversions from pointer-to-attributed-type and pointer-to-type
interact?  Do the attributes act like qualifiers where you have
to be going in the more qualified direction to make the conversion
without a cast?  That makes sense for things like `noreturn', since
a non-returning function is a special case of a function.  But
not for things like `mode' or `stdcall' where there is no natural
conversion in either direction.  Does const_cast or static_cast make
these converions, or do you need reinterpret_casdt?  Egads.

Also, your well-formed-only-if-well-formed-without-attributes rule is
interesting, because we certainly won't have the same semantics
with and without the attributes; in the typeid case,
if we give different typeids to types with different attributes, tests
will come out backwards of how they would without attributes.

> They are different - meaning "pointer to stdcall function" and "stdcall
> pointer to function" - though the latter doesn't make semantic sense and
> valid_machine_attribute will apply the attribute to the function type
> having failed to apply it to the pointer.  (Users expect function
> attributes applied to pointers to functions to work like this, e.g.
> c/3481.)

Great.  So, in other words, we have a reasonably sensible semantics (the
one you give), but that's not the one we implement, and maybe not
the one that people actually want.  Ugh.

> There is a reasonably clean syntax subset - but it isn't the most usual
> way in which people use attributes.  It is:

See above.

The problem is that I think we're playing a losing game: the 
backwards-compatibility issues mean that I don't think we get to
figure out what this feature should have been.  Instead, we are stuck
with what it is.

We were very irresponsible when we implemented these features
without thinking them through.

I should continue this tradition by simply implementing something roughly 
similar to what is there now without bothering to think about it any more. 
Probably, that would change the meaning of some programs, break some
others, and enable some entirely new programs.  However, I will try
to be vaguely more conscientious.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com