On Tuesday, August 22, 2017 01:01:15 Nicholas Wilson via Digitalmars-d wrote: > 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).
Which is precisely why I don't like it. Fixing non-invertibility is great. I don't like any of the rest. > 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. Regardless, it means that I would need to run a tool to figure out which attributes actually applied to a function rather than just reading it like I could do now. And the fact that this is can be done with UDAs right now is _not_ a plus. I can understand wanting to reduce the number of attributes being manually applied to functions, but I think that hiding them with aliases and/or combined attributes is a maintenance nightmare and would argue that it's just plain bad practice. - Jonathan M Davis
