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.@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