@safe(bool)

[Nicholas Wilson via Digitalmars-d]

On Monday, 21 August 2017 at 08:09:25 UTC, Jonathan M Davis wrote:
> Except that someone could then be pulling in attributes from 
> 3rd party libraries and using those, meaning that you'll 
> potentially have to go digging through other libraries just to 
> figure out whether a function is being marked with @safe or 
> not. You get some of that pain with any custom attribute, but 
> currently, the built-in attributes avoid it completely, and 
> being able to combine attributes makes it far worse, since then 
> you potentially have to go searching through a chain of 
> declarations to figure out which attributes are actually being 
> used. I can understand folks wanting to reduce how many 
> attributes they have to manually put on functions, but I think 
> that it risks being a maintenance nightmare to have to deal 
> with combined or aliased attributes. I would _much_ rather see 
> each attribute applied individually, because it's far easier to 
> figure out what's going on that way. We already have enough 
> problems figuring out which attributes are in play when dealing 
> with attribute inference. I _really_ don't want to see aliasing 
> and combining added to the mix - especially with the built-in 
> attributes. And that seems to be one of if not the main 
> motivation of the DIP.
>
> - Jonathan M Davis

That attributes are combinable and aliasable are nice side 
effects of being regular attributes which in general are one of 
the main foci of the DIP (the other being fixing the 
non-invertibility).

Any editor that has dcd (or other tooling) support should be able 
to immediately resolve which aliases refer to what as its only 
symbol resolution. Yes it won't be able to do inference but it 
can't under the current system either.