@safe(bool)

[Nicholas Wilson via Digitalmars-d]

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.