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

Sönke Ludwig ludwig_nospam at informatik.uni-luebeck.de
Sun Feb 28 01:40:10 PST 2010


I would also tend to agree that this set of rules is a bit arbitrary
and seems a bit like some overfitted classifier in pattern recognition
(although there were worse sets or rules in that regard).

Jugding from the numerous failed, awkward or too specific attempts to
define such a set of rules, maybe it would be better to admit that
there is no clear, boolean rule possible.

Instead we could define a set of measurements against which each
keyword is weighted empirically to choose the optimal form
(attribute/keyword) on a case-by-case basis. Such rules could be for
example:

  - needed changes when porting from C/C++
  - frequency of use - @ is quite disrupting, both, in terms of typing
    and reading
  - if it changes the syntax used for accessing the annotated entity it
    probably should not be an attribute (e.g. property or type
    constructors)
  - interference with user code - how likely is it to get name clashes
    with user variable/function names

Obviously there would some disagreement for the third rule - I am
definitely for property as a keyword - but that aside, I think this
approach would prevent us from pretending something which is not there
and also does not lead to possibly silly forced desicions for future
keywords.

Sönke



More information about the Digitalmars-d mailing list