Custom attributes (again)

[Artur Skawina]

On 04/06/12 11:18, Ary Manzana wrote:
> On 4/6/12 3:54 PM, Walter Bright wrote:
>> On 4/6/2012 12:49 AM, Alex Rønne Petersen wrote:
>>> What about type declarations? I think those ought to be supported too.
>>> E.g. it
>>> makes sense to mark an entire type as @attr(serializable) (or the
>>> inverse).
>>
>>
>> That would make it a "type constructor", not a storage class, which we
>> talked about earlier in the thread. I refer you to that discussion.
> 
> What's the difference between "type constructor" and "storage class" beside the name?

@attr(deprecated) struct T { int blah; } // every instance of S now marked with it.

struct S { int blah; }
@attr(deprecated) S si;  // just si marked; think "static S si;" etc


I actually don't like the proposed scheme - it's both way to verbose and not
nearly sufficient.

I have to leave soon and don't have the time to fully describe the problems, but
just a few key points:

- Both of the above should work; the "storage class" is the more important part.
  Wouldn't just having the type-attributes automatically propagate (as a default
  "storage class") to the instances, w/o affecting the type in any way, be enough?
- If the above would work, then there has to be a way to remove an attribute from
  some instances.
- Attributes needs to be declared in some way, otherwise a typo will go undetected
  and you may not notice it until it's too late. Think "@attr(serialisable)" etc
- Attributes need to be mergeable, ie you really don't want to mark a significant
  number of symbols as serializable, exported-to-X, exported-to-Y etc. Something
  like 
  "alias @attr("serializable", "export_X", "export_Y") new_attr"; @attr(new_attr) int i;"
  might work.
- At the very least "__traits(getAttribute, x, foo)" needs to be something like 
  "__traits(@attr, x, foo); even better would be "x. at attr("foo");".
- Should attributes be strings? That would avoid clashes with keywords. OTOH
  that would mean that attribute definitions needs to use different syntax than
  plain structs. Hmm, maybe that would be a good thing anyway.
- Namespaces. There needs to be a system NS and a compiler-specific NS. So that
  you can do things like @attr(__GNU, "flatten", "hot") instead of 
  "pragma(GNU_attribute, flatten, hot)". 
- Null/empty attributes, ie "alias @attr() new_attr;", should work; necessary eg
  when the compiler lacks support for certain features.

There are probably many more issues, these are just the few obvious ones that
immediately come to mind.

artur