DIP6: Attributes

[Don]

Steven Schveighoffer wrote:
> On Mon, 03 Aug 2009 11:42:33 -0400, Ary Borenszweig 
> <ary at esperanto.org.ar> wrote:
> 
>> Don wrote:
>>> Ary Borenszweig wrote:
>>>> Don escribió:
>>>>> grauzone wrote:
>>>>>> Don wrote:
>>>>>>> Ary Borenszweig wrote:
>>>>>>>> http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6
>>>>>>>
>>>>>>> This looks like a solution in search of a problem. What's the 
>>>>>>> problem being solved?
>>>>>>
>>>>>> Attaching additional data to types, that can't be specified 
>>>>>> otherwhere. This should help with metaprogramming-like stuff.
>>>>>>
>>>>>> For example serialization. How do you specify that a field 
>>>>>> shouldn't be part of the serialized data? Java has an extra 
>>>>>> keyword attribute like
>>>>>> "transient" (comes from before attributes were introduced). C# 
>>>>>> uses what we call annotation in this thread. How would you do this 
>>>>>> in D?
>>>>>
>>>>> I agree that there doesn't seem to be a nice way at present. One 
>>>>> possibility would be to establish a naming convention for transient 
>>>>> fields -- a Ruby-style solution, I guess.
>>>>>
>>>>> But are annotations actually an ideal solution for this problem?
>>>>> Presumably, you'll have to specify that somewhere else anyway. I 
>>>>> mean, during reading it will need to either be initialized 
>>>>> separately after serialisation (like opPostBlit, perhaps?), or else 
>>>>> remain uninitialized. Serialisation seems to be _extremely_ similar 
>>>>> to construction. I'm not sure that annotations capture that.
>>>>>
>>>>> D has much more powerful metaprogramming than C# or Java, so my 
>>>>> intuition and hope is that we shouldn't need to adopt hacks from 
>>>>> those weaker languages. The annotation syntax in C# and Java looks 
>>>>> like an ugly hack to me. Purely a subjective opinion, of course, 
>>>>> but it seems really out of place in a C-family language.
>>>>
>>>> Attributes has many, many other uses. Appart from serialization, you 
>>>> could specify how a field is stored in a database. How a method maps 
>>>> to an http request (post, get, which parameters to bind to the 
>>>> request, etc.). Whether a method should do security checks before 
>>>> executing. Whether a method should be run as a test, and what's the 
>>>> expected exception to be thrown. [insert your usage here]
>>>  Great, you've answered my question. That should be in the DIP, 
>>> instead of the vague stuff that's in there now -- the existing DIP is 
>>> about replacing keywords, which is very unconvincing. (It doesn't 
>>> work, actually -- the name mangling is important for most of the 
>>> keywords mentioned).
>>
>> But the DIP I wrote isn't about general-purpose annotations. It's just 
>> the first step. Are "pure" and "nothrow" part of the mangling? Or 
>> which are? I thought not. Can you overload a pure and a not-pure 
>> function with the same parameter count and types?
> 
> Yes, they have to be.  There are reasons besides overloading for 
> including other attributes in the naming.
> 
> For example, if a function is pure, then becomes unpure, you don't 
> existing code that is expecting a pure function to link against it.
> 
> In other words, the linker is dumb.  It only knows how to match symbols, 
> so you have to embed into the symbols the important pieces of the 
> interface that you want the linker to consider important.


A question: in C#/Java, can you have annotations on function pointer and 
delegate declarations?

void foo( int delegate(int) pure dg) {
   ...
}
What would this look like with annotations?

(The underlying question is, how do annotations interact with the type 
system?)

> To answer Don's point, there is nothing saying that the compiler can't 
> read attributes and change its behavior.  Of course, those would have to 
> be builtin attributes.

Yes, but then they're just keywords, with an @ in front. You'd just be 
kidding yourself if you think you've reduced the keyword count.

> My opinion on removing existing keywords is -- don't.  There's little to 
> no gain.  Let that ship sail, and concentrate on future keyword proposals.
> 
> -Steve