@safe(bool)

[Jonathan M Davis via Digitalmars-d]

On Monday, August 21, 2017 10:41:49 Danni Coy via Digitalmars-d wrote:
> > For instance, as it stands, it's relatively easy to figure out whether
> > @safe
> > has been explicitly applied. You can look on the function and look for
> > @safe: or @safe {} which affects it. The same goes for other attributes.
> > But
> > as soon as you can do stuff like create new attributes that combine
> > attributes, you lose that completely. Suddenly. you have to worry about
> > whatever attributes someone came up on their own for their project which
> > apply @safe or final or @nogc or whatever. You can no longer search or
> > grep for an attribute like @safe to see whether it applies.
>
> you can still search or grep but it's now a two step process. when you
> grep the @safe attribute you will find the custom attribute declaration.
> you then search for the custom declaration. You need to do the first step
> exactly once for each codebase (unless you forget).
>
> It's more diffucult but only a little bit.

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