On 18 March 2012 03:10, Walter Bright <newshound2@digitalmars.com> wrote:
On 3/17/2012 2:55 PM, Manu wrote:
I tend to think of 'struct's as 'passive', and compile-time annotations would
provide me with every use case I can imagine for my own purposes in the case of
structs. classes seem far more likely to need stateful attributes.

I currently find the notion of runtime attribute state to be fraught with all kinds of unresolved and murky issues with no obvious answer:

1. construction/destruction

After initialisation, before construction.

2. shared

How is this any different than for the class its self?

3. const/immutable

Inherit these properties.

4. thread locality

Same as class.

5. allocated statically or dynamically

I'd say dynamically if restricted to classes, but some suggested the syntax '@attribute struct/class MyAttribute { }', which could clarify the intent.

6. shared library issues?

If extern(D), then there should be no problems. If extern(C), then the attributes would just appear like structure members. Assuming the layout was documented (ie, in-order of appearance, at the end of the class), C/C++ could include them at the end of the class definition, and access them directly as if usual classes. All that would be lost is the implicit (compile time) association between the attribute and its associated class member.
I don't think it's fair to expect a novel language feature to be supported by C/C++ though.


If the attribute is code, when does that code get run?

1. on initialization
2. on termination
3. on read
4. on write
5. what about read/write?

I might go and read up on C# more thoroughly and get back to you... maybe others here are already more familiar with C#'s attribute management?
I'm sure C# already answers all these questions. It has precisely the same set of issues associated.