@safe(bool)

[Timon Gehr via Digitalmars-d]

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.