@safe(bool)

[Nicholas Wilson via Digitalmars-d]

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.