@safe(bool)

[Jonathan M Davis via Digitalmars-d]

On Friday, August 18, 2017 03:08:07 Nicholas Wilson via Digitalmars-d wrote:
> On Friday, 18 August 2017 at 01:43:42 UTC, Jonathan M Davis wrote:
> 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.

IMHO, the problem that needs solving is that you can't negate attributes,
making stuff like

final:

problematic. DIP 1012 goes way beyond that, and I don't think that that
extra stuff is at all worth having, and I do think that it's detrimental.
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. Similarly, having it
be possible to alter the default attributes globally is incredibly bad IMHO.
Suddenly, whether your module compiles or not could depend on what settings
someone used for the default attributes. That should not be controlled
externally. It should be part of the module just like whether a function or
variable is const or not is part of the module and not defined externally.
IMHO, it makes no sense whatsoever to have something external control
attributes any more than it makes sense to control the return types or
constness of symbols externally. That should be part of the
declarations/definitions of the symbols in question. And slapping something
like @safe: at the top of the module solves the problem of applying
attributes to an entire module right now just fine except for the fact that
you can't negate attributes, meaning that aside from the few that have
multiple states (namely, the @safety and access level attributes), you can't
alter the attributes on specific functions if you mark the whole module with
a particular attribute. So, we really should have a solution for negating
attributes, but I don't at all agree that the rest of what DIP 1012 is
trying to do is beneficial.

I honestly think that what DIP 1012 is trying to do beyond making it
possible to negate attributes is going to make the language worse and code
harder to maintain. Yes, it will enable some things that you can't do now,
but for the most part, I don't think that those things should be enabled. I
don't want to have to deal with folks complaining that my library doesn't
work right, because they tried a different default for the attributes with
it. I don't want to have to worry about trying to get someone else's code to
work because they assumed something about the default attributes that does
not hold in my case. I don't want to have to track down every custom
attribute that someone came up with just to see whether they actually apply
attributes like @safe or nothrow, just so that I can see whether those
attributes apply. I should be able to look at a module and see which
attributes have been applied to the functions in that module without having
to go searching elsewhere.

IMHO, what needs to be solved with the built-in attributes, is the ability
to negate the ones that don't have multiple states. With that, what we have
now will work just fine. The rest is completely undesirable.

- Jonathan M Davis