UDAs - Restrict to User Defined Types?

[Nathan M. Swan]

On Wednesday, 7 November 2012 at 23:18:41 UTC, Walter Bright 
wrote:
> Started a new thread on this.
>
> On 11/7/2012 3:05 AM, Leandro Lucarella wrote:
> > OK, that's another thing. And maybe a reason for listening to
> people having
> > more experience with UDAs than you.
> >
> > For me the analogy with Exceptions is pretty good. The issues
> an conveniences
> > of throwing anything or annotating a symbol with anything
> instead of just
> > type are pretty much the same. I only see functions making
> sense to be accepted
> > as annotations too (that's what Python do with annotations,
> @annotation symbol
> > is the same as symbol = annotation(symbol), but is quite a
> different language).
>
> There's another aspect to this.
>
> D's UDAs are a purely compile time system, attaching arbitrary 
> metadata to specific symbols. The other UDA systems I'm aware 
> of appear to be runtime systems.
>
> This implies the use cases will be different - how, I don't 
> really know. But I don't know of any other compile time UDA 
> system. Experience with runtime systems may not be as 
> applicable.
>
> Another interesting data point is CTFE. C++11 has CTFE, but it 
> was deliberately crippled and burdened with "constexpr". From 
> what I read, this was out of fear that it would turn out to be 
> an overused and overabused feature. Of course, this turned out 
> to be a large error.
>
> One last thing. Sure, string attributes can (and surely would 
> be) used for different purposes in different libraries. The 
> presumption is that this would cause a conflict. But would it? 
> There are two aspects to a UDA - the attribute itself, and the 
> symbol it is attached to. In order to get the UDA for a symbol, 
> one has to look up the symbol. There isn't a global repository 
> of symbols in D. You'd have to say "I want to look in module X 
> for symbols." Why would you look in module X for an attribute 
> that you have no reason to believe applies to symbols from X? 
> How would an attribute for module X's symbols leak out of X on 
> their own?
>
> It's not quite analogous to exceptions, because arbitrary 
> exceptions thrown from module X can flow through your code even 
> though you have no idea module X even exists.

In module sql.d:

     /// For every field marked ["serialize"], add to table
     void saveToDatabase(T)(DBConnection db, T model);

In module json.d:

     /// For every field marked ["serialize"], add to JSON object
     string jsonSerialize(T)(T obj);

In module userinfo.d:

     ["dbmodel"]
     struct UserModel {
         ["serialize"] string username;
         // What do you do if you want this in the database, but 
not the JSON?
         string password;

         ["serialize"] Content ownedContentOrWhateverThisWebsiteIs;
     }

The only solution to this question is to differentiate 
"db_serialize" and "json_serialize"; looks a lot like C, doesn't 
it?

My suggested soluion: @annotation (with [] UDA syntax):

     module sql;
     @annotation enum model;
     @annotation enum serialize;

     module json;
     @annotation enum serialize;

     module userinfo;
     import sql, json;

     [sql.model]
     struct UserModel {
         [sql.serialize, json.serialize] string username;
         [sql.serialize]                 string password;
         [sql.serialize, json.serialize] Content content;
     }

My thoughts,
NMS