DIP6: Attributes

[Steven Schveighoffer]

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.

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.

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