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.
