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

[Jonathan M Davis]

bearophile wrote:

> Jonathan M Davis:
> 
>> Changing public or private to be attributes would be
>> quite disconcerting given how C++, Java, C#, D1, etc. all have them as
>> keywords. And making them attributes would make porting code that much
>> harder. It seems entirely valid to me.
> 
> I think that making public or private as attributes requires just a
> textual search & replace of the lowercase string "public" with "@public"
> and the same for private. This change requires a small time even if you
> don't use an IDE. And IDE can even allow you to avoid to replace those
> words if they are inside a comment/string. In comparison to this, the
> recent D2 change of fixed-sized arrays that are now passed by value and
> not by reference needs in my opinion more care when you translate C code
> to D.
> 
> Bye,
> bearophile

Oh, it's far worse than that. In C++, public and private are labels. They 
don't go on each individual function. You'd probably have to parse the code 
to correctly, automatically manipulate the labels into attributes. And D 
supports public and private as labels in addition to going on each function, 
so you'd have the problem with both C++ and D code. What you suggest would 
work for Java, and I'm pretty sure that it works for C# (it's been a while 
since I've coded in it though, so I don't recall for certain which way they 
use public and private), but for C++, D1, and older D2 code, it wouldn't 
work.

So, unless the suggestion is that public and private be allowed as labels, 
and then when they're used on functions, they're now attributes, then simple 
text replacement doesn't work. And I really think that leaving them as 
labels and having them as attributes on functions would make the two uses 
too different.

Besides, I see no gain in making public and private attributes. They're 
already keywords, if you leave them as labels, they have to remain keywords, 
so I see no gain in making them attributes. It just makes porting code 
harder.

- Jonathan M Davis