Should pure nothrow ---> @pure @nothrow ?

Lars T. Kyllingstad public at kyllingen.NOSPAMnet
Fri Nov 27 05:10:34 PST 2009


Don wrote:
> Lars T. Kyllingstad wrote:
>> Don wrote:
>>> #ponce wrote:
>>>>> Definitely. And what about @deprecated and @override?
>>>>
>>>> As override is now required, i don't think it should be an attribute.
>>>
>>> As I understand it, one of the characteristics of attributes is that 
>>> you should be able to remove them from the entire program, without 
>>> affecting the behaviour.  All they are doing is adding additional 
>>> compile-time constraints. (const and immutable aren't attributes, 
>>> because you're allowed to overload functions based on them).
>>
>> If this is the rule, shouldn't the protection attributes be moved into 
>> the annotation namespace as well? (@private, @protected, @package, 
>> @public) Since everything is public by default in D, a program will 
>> keep working even if you remove them.
>>
>> NOTE: I don't necessarily think they should, but I do think there 
>> should be a definite rule for which attributes are @annotations and 
>> which aren't. Otherwise it just seems random.
>>
>> -Lars
> 
> Obviously my rule isn't correct. It's hard to come up with a rule that 
> includes @property, without including everything else.

That's what I suspected. How about saying that annotations only provide 
compile-time constraints on the body, i.e. the internals, of the 
function being annotated?

Then, the following would be annotations:

   @safe, @unsafe, @system, @pure, @nothrow

while the following would have to be ordinary keywords:

   property, private, public, deprecated

-Lars



More information about the Digitalmars-d mailing list