On Thursday, 8 November 2012 at 13:19:29 UTC, Jacob Carlborg wrote:
> On 2012-11-08 11:56, simendsjo wrote:
>>> Or
>> struct @foo {}
>> interface @foo {}
>> enum @foo {0
>> etc
>> That syntax looks a bit backwards to me. What if I want to annotate the attribute.
>> @serializable struct @foo {}
>> Looks a bit confusing which is the name of the attribute and the which is the attached annotation.
>> Vs
>> @serializable @attribute struct foo {}
>> No confusion here, "foo" is the name of the attribute, the rest is attached annotations.
I guess it depends. I find it easier to see that it's an attribute, especially when you annotate it. But it's harder to grep for.
Is foo an attribute or not?
@serializable
@xmlRoot
@attribute
@displayName("foo")
struct foo {}
Is foo an attribute or not?
@serializable
@xmlRoot
@displayName("foo")
struct @foo {}

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

On Friday, 9 November 2012 at 03:45:11 UTC, Nick Sabalausky wrote:
> the *one* thing I hate about D ranges is that they don't force you to explicitly say "Yes, I *intend* this to be an InputRange" (what are we, Go users?).
Just a note, of course it still wouldn't *force*, but maybe it'd be a good habit to start writing this:
struct myrange {...}
static assert(isInputRange!myrange);
It'd be a simple way to get a check at the point of declaration and to document your intent.
Interestingly, we could also do this if the attributes could run through a template:
[check!isInputRange] struct myrange{}
@attribute template check(something, Decl) {
static assert(something!Decl);
alias check = Decl;
}
Same thing, diff syntax.