On Sunday, 20 August 2017 at 01:33:00 UTC, Nicholas Wilson wrote:
>
>  I'm not quite sure how this would lead to a loss of modularity?

Not sure if modularity is exactly the right word. The problem would be akin to extension methods in C#, or even a useful set of UFC's in D.

So, imagine you decide you need DateTime.LastWeek() or something similar. This turns out to be something you end up needing in most of your projects. So first of all, you're now required to start bringing this file into every project you work on. This is already annoying. Then, one day, you decide you also need DateTime.FortnightAgo(). So you add it to the file, except that all the other versions are now out of sync. You think, maybe I should have made a repository!? First of all, too late. Second, you now have to clone a repo into all your new projects instead of dragging and dropping a file, and update the repo every time you want to work on the project in case anything changed. At this point, any reasonable person would be frustrated....but wait...you also need some extensions for Math as well, which are not necessarily related to the extensions for DateTime. I suppose you could start throwing together your own small support library with all of these things in there... But wait...some of the extensions are platform specific *facepalm*. So eventually, you end up with a chart like this[1] describing which of these libs are in each of your projects.


The catch is, that a lot of the time, the things you make are these extensions for are so ubiquitous that they should probably just be included in the language, or standard library. An easy example is the million different variations of C++ "thread", "mutex" and "hashtable" that were built while the C++ community took a coffee break from 1998 to 2011 ;)

I think I've painted the picture sufficiently at this point.

[1] http://i.imgur.com/cQxxQJs.png

> 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.

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

On Monday, 21 August 2017 at 08:09:25 UTC, Jonathan M Davis wrote:
>
> you potentially have to go searching through a chain of declarations to figure out which attributes are actually being used.

A good IDE should give you this info if you hover over a function. I realize D's tool support is spotty at the moment, but it seems like the kind of think that's ok to be optimistic about.

On Tuesday, August 22, 2017 00:21:16 bitwise via Digitalmars-d wrote:
> On Monday, 21 August 2017 at 08:09:25 UTC, Jonathan M Davis wrote:
> > you potentially have to go searching through a chain of declarations to figure out which attributes are actually being used.
>
> A good IDE should give you this info if you hover over a function. I realize D's tool support is spotty at the moment, but it seems like the kind of think that's ok to be optimistic about.

If you need an IDE to figure out what your code is doing, that's an epic fail IMHO. Walter has made similar statements on several occasions. D was originally designed in such a way that IDEs should not be necessary (e.g. it tries to avoid a lot of the boilerplate code that is typical in Java programs). Most of the folks around here do not use IDEs. I use (g)vim as my code editor, and I have no desire to use an IDE. I should be able to figure out what's going on just by looking at the code, and having to go spelunking to figure out which attributes really apply because they're hidden behind aliases or combined in other attributes is just wasting my time IMHO. As long as the attributes are applied directly without being renamed (be it directly on the function or to the module as a whole), then the situation is quite tractable, but if we end up with aliased attributes and combined attributes, that goes completely out the window.

- Jonathan M Davis

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.

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

On Tuesday, 22 August 2017 at 01:20:13 UTC, Jonathan M Davis wrote:
> On Tuesday, August 22, 2017 01:01:15 Nicholas Wilson via Digitalmars-d wrote:
>> 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

Then we shall just have to agree to disagree. I am of the opinion that they are very useful properties of UDAs and that's part of why I wrote that DIP.

Am Sun, 20 Aug 2017 00:29:11 +0000
schrieb Nicholas Wilson <iamthewilsonator@hotmail.com>:

> On Saturday, 19 August 2017 at 17:10:54 UTC, bitwise wrote:
> > I'm still concerned about having to read code that's laced full of custom attributes, the resolution of which may span several files, templates, etc.
> >
> > I also think this type of thing could have a detrimental effect on modularity when you end up having to include "myAttribs.d" in every single file you want to work on. I would much rather have a flexible in-language solution, or a solution that didn't require me to define my own attributes.
> 
> Having worked on a project with a lot of attributes, my suggestion would be to import it via a package.d, you'll be importing that anyway.

+1
A bigger project /usually/ has some default imports. Typical
use cases are unifying compiler versions and architectures,
back-porting new Phobos features and custom error handling and
logging.
For example, in dub the modules in the "internal" package are
imported into most of the bigger modules.
You can also create a file template with documentation header,
license and default imports if you need to create a lot of
modules.

-- 
Marco

On 8/21/17 9:20 PM, Jonathan M Davis via Digitalmars-d wrote:
> 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.

Not for or against the DIP, but this is already the case, due to block attributes. I have to search around the file to find out whether pure: is at the top, etc. In fact, I've made recommendations many times on PRs to add an attribute to a function, to find out it's already handled at the top.

I would think documentation generation should solve the issues.

-Steve