On 18.08.2017 17:16, bitwise wrote:
On Friday, 18 August 2017 at 01:43:42 UTC, Jonathan M Davis wrote:
[...]
- Jonathan M Davis
Makes sense to me.
The first question that comes to mind is if the extra generality
provided by DIP 1012 is actually useful, let alone, worth breaking
changes. The rationale section of the DIP only mentions negating
attributes, which is easily accomplished with what I suggested. Unless
that section is expanded with additional practical use cases, then it
doesn't seem worth the trouble to me.
...
It's a vastly better design, because it does not try to overfit to a
single use case. E.g. it allows abstracting over attributes. You can
have an alias that contains sequences of attributes and then apply the
summary:
alias naughty = AliasSeq!(impure,system,throws,gc);
alias nice = AliasSeq!(pure,safe,nothrow,nogc);
@nice void foo();
@naughty void bar();
The DIP mentions tagging a module declaration with default attributes.
If the whole purpose of the DIP is to allow for negating attributes, why
would you even need this change, when the DIP would effectively make it
ok to put "@nogc: @safe: @etc:" at the top of the file?
My suggestion does not cover "inferred" as discussed in the DIP, but
that could be achieved by letting something like "@default" reset all
attributes for a given symbol.
I'll concede that DIP1012 makes more logical sense than the current
state of things, but it seems like something that would be best achieved
during a transition to a subsequent language version. It seems
commonplace here, to discard suggestions based on their current
viability, when it may be better to add them to a feature backlog that
could be considered when talking about the possibility of a D3.
There are non-awkward backwards-compatible ways to implement DIP 1012.