Proposal: user defined attributes

[F i L]

On Monday, 19 March 2012 at 20:44:43 UTC, Andrej Mitrovic wrote:
> On 3/19/12, Jacob Carlborg <doob at me.com> wrote:
>> * Can be repeated on several fields (with the mixin you can 
>> only mixin
>> "NonSerialized" once)
>
> When I implemented NonSerialized for Vladimir's json library he 
> made a
> suggestion to simply create enums of each field that is not to 
> be
> serialized and encode it as "fieldname_nonSerialized". That 
> would
> enable using a NonSerialized mixin multiple times.
>
> I've yet to implement it in that way, I ran into some odd bugs 
> but
> I'll have a look at this soon. My implementation used a hash 
> lookup
> table for the fields, but using enums would make the code even
> simpler. Basically:
>
> struct Foo
> {
>     int x;
>     string name;
>     mixin(NonSerialized!name);
>     string lastName;
>     mixin(NonSerialized!lastName);
> }
>
> and this would expand to:
> struct Foo
> {
>     int x;
>     string name;
>     enum name_nonSerialized;
>     string lastName;
>     enum lastName_nonSerialized;
> }
>
> So all you'd have to do is use compile-time introspection and a 
> little
> bit of string processing to figure out if a field should be 
> serialized
> or not.


I think this could get tricky for the compiler to confidently use 
given that the mixed in enums can collide with existing members 
(although not likely). Also, if objects are not identified as 
being unique marked (in the compilers eyes), what specific 
attribute post-fixes will it be searching for on enums members?