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