On Friday, 18 August 2017 at 15:16:55 UTC, 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.
It fixes the non-inverability. They become regular attributes
instead of keywords. This has the effect of separating their
definition from their usage allowing you to manipulate them like
normal attributes, see https://github.com/dlang/DIPs/pull/89/ for
the most recent revision.
The only breaking changes are nothrow and pure get a leading '@'.
They will go through a proper deprecation process and I will be
very surprised if anything breaks. The new symbols added to
core.attributes can use `@future` if need be to further reduce
the likelihood of any 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.
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?
This is changed in pull #89.
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.
How would you know what attributes were in effect before?
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.
Why? Breakage will be completely contained with transitional
behaviour, i.e. the compiler will treat pure as @pure and nothrow
as @nothrow. I can't think of any other facets that would warrant
semi-indefinite delay.
