A rationale for pure nothrow ---> @pure @nothrow (and nothing else changes)

[Michel Fortin]

On 2010-02-24 21:32:57 -0500, Don <nospam at nospam.com> said:

> We'll need compile-time reflection for all attributes. This can lead us 
> to a rationale for which attributes are keywords, and which are 
> @attributes.
> 
> For @ attributes, we can have a syntax vaguely like:
> __traits(hasAttribute, "safe", foo);
> The details aren't important, but it seems clear that we'll need some 
> such thing.
> 
> Anything which isn't an @ attribute will need to have its own traits 
> support. We want to minimize the number of such special cases.

Deciding whether something is an attribute or not depending on how it's 
easier to express them in __traits sounds like a bad idea to me.


> Here are some rules.
> 
> * If it exists as a keyword in C++, it is not an @attribute.
> * hasAttribute is never used for identifying conditional compilation.
> * If accessing it via a standard hasAttribute syntax will reduce the 
> number of reflection special cases, it should have an @ prefix.

I don't like any of these rules. The language shouldn't be primarily 
designed to ease reflection, it should be designed to be easy to learn 
and understand.


> Note that some attributes, though not keywords in C++, are intimately 
> tied to other features which are C++ keywords. So the combination of 
> rule 1 + rule 3 stops them from being @ attributes.

That's getting messier and messier. You shouldn't have to know C++ when 
learning about attributes in D, and even less about what features of D 
are "intimately tied" to some other feature in C++.


> I know these rules are a little ad-hoc, and aren't as unambiguous as we 
> might hope, but I think they do give us the consequences that we want. 
> Importantly, it lets @property continue as an attribute.

Why is it important that @property continues to be an attribute? To me 
@property is the attribute that is farthest to what I expect an 
attribute to be.

To me, an attribute should be seen like this:

"""
If something is an attribute, then it's accessory to the language. 
Something is accessory when you can remove it completely from a program 
and expect the program to compile and behave the same. Attributes are 
not changing anything beside adding some restrictions to improve 
safety, optimization, etc.
"""

This rule is easy to understand and is useful for newbies who then know 
they can simply ignore attributes in the code they read. Making things 
ignorable sort of diminish the language complexity while learning.

Also, while it limits what can be attributes to accessory things, it 
doesn't forbid things that could be attributes from being keyword if 
they're judged important enough to be not accessory.


> private, protected, public:
> No. Keywords in C++.
> package:
> No. Tied to the other protection classes. Once the others are out, we 
> don't benefit from hasAttribute syntax for the last survivor.

These could almost be attributes by my definition(*). But I agree there 
is a big precedent in many other languages to make them keywords. And 
you could say visibility protection is important enough and not 
accessory.

(*): The only thing preventing 'private' and 'protected' from being 
attributes is that they also have the side effect of making functions 
non-virtual, which is incompatible with my definition of an attribute.


> deprecated:
> No. This is equivalent to version(deprecated), but with better error 
> messages. Not an attribute.

This isn't equivalent to version(deprecated) at all. Deprecated 
function are still compiled and put in the resulting object, and can be 
called freely from other deprecated functions and from non-deprecated 
function when the compiler flag is on. It's more comparable to pure, 
nothrow, and @safe in that it's adding a restriction regarding who can 
call the function.

For instance, make you main() deprecated and it'll be able to call any 
deprecated function without the compiler flag. :-)

I'd tend to make it an attribute.


> virtual:
> No. keyword in C++.
> override:
> No. Tied to virtual.

I think it makes sense for it to be a keyword only if it is mandatory. 
Otherwise it's just an accessory thing you can discard at will.


> safe, trusted, system:
> Yes.

Fine with me. A program can compile and work fine if you remove all 
these attributes everywhere, so they're accessory.


> property:
> Yes. We can avoid a reflection special case.

I think this one is the silliest of all attributes. It does change the 
syntax of the function call, and sometime also the semantic meaning of 
the name, so it's not accessory at all. You can't discard it and expect 
things to work fine. So it definitely should not be an attribute.


> pure, nothrow:
> Yes. These should change.

Fine with me. A program can compile and work fine if you remove these 
two attributes everywhere, so they're accessory (though useful for 
optimization and other things).


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/