On Friday, 18 August 2017 at 01:43:42 UTC, Jonathan M Davis wrote:
On Thursday, August 17, 2017 19:21:16 Timon Gehr via
That makes little sense to me, as DIP 1012 is strictly more
general.
Whereas this solves the problem with DIP 1012 claims to be
solving without adding a bunch of extra stuff that IMHO makes
the built-in attributes more complicated for no real benefit as
well as having some stuff in it that would effectively split
the language into multiple variants where code will compile
with some but not others (most notably, allowing for the
default @safety level to be globally altered as opposed to
doing something nice and portable like @safe: at the top of a
module).
As I explained in that thread it adds very little complication,
keyword like attributes become enum; last applied wins. If
anything its reduces complexity as attributes, both builtin and
user defined, become regular attributes. W.r.t global altering, I
expect that it would be used by applications (rarely, e.g.
embedded environments for nothrow nogc final) not libraries. It
is also only part of the DIP.
As I explained in the initial discussion in DIP 1012,
it does a whole pile of stuff that has nothing to do with its
stated goal, and I think that most of the other stuff that it
does is detrimental, whereas if what's proposed here were
implemented for more than just @safe, it would actually solve
the stated goal of allowing attributes to be negated and thus
fix the problem that doing something like putting final: at the
top of a class can't be undone.
If you think that then I have clearly failed to express the DIP
at all.
It solves exactly that. I completely fail to see how it is a
detriment to anything.
The 'whole pile of other stuff' is reduced in further revisions
to the DIP.
Andrei previously proposed essentially what the OP proposed,
but no DIP was ever created for it, and it's never happened. It
probably would stand a decent chance of making it through
though, since it solves a real problem, and Andrei has
previously shown interest in this solution.
And there was real interest in DIP 1012, which was the whole
reason I wrote it, and
I reject your notion that DIP 1012 does not solve a problem.
