On Sunday, 23 April 2017 at 12:03:47 UTC, Andrei Alexandrescu wrote:
> On 4/22/17 4:52 PM, Joakim wrote:
>> Why is this still up for review?
>
> Mostly out of a sense of conformity. We asked Michael to give no special treatment of DIPs originating from us, and this one was open, so he put it up for review. It is likely it will end up rejected in favor of https://github.com/dlang/druntime/pull/1756.

The DIP mentions dependency-tracking tools, an important consideration. For both the DIP and the PR it'd be worth identifying if changes will be required in D dependency-tracking tools (dmd/ldc/gdc --deps; rdmd --make-depends) or 3rd party tools in common use.

--Jon

On Saturday, 22 April 2017 at 11:54:08 UTC, Mike Parker wrote:

> All review-related feedback on and discussion of the DIP should occur in this thread. Due to DConf taking place during the review period, the period will be extended by a week. The review period will end at 11:59 PM ET on May 13 (3:59 AM GMT on May 14), or when I make a post declaring it complete.

Reminder: There are two weeks remaining in the review period.

On Saturday, 6 May 2017 at 10:38:25 UTC, Mike Parker wrote:
> On Saturday, 22 April 2017 at 11:54:08 UTC, Mike Parker wrote:
>
>> All review-related feedback on and discussion of the DIP should occur in this thread. Due to DConf taking place during the review period, the period will be extended by a week. The review period will end at 11:59 PM ET on May 13 (3:59 AM GMT on May 14), or when I make a post declaring it complete.
>
> Reminder: There are two weeks remaining in the review period.

Sorry, *One Week* remaining.

On Saturday, April 22, 2017 11:54:08 Mike Parker via Digitalmars-d wrote:
> DIP 1005 is titled "Dependency-Carrying Declarations".
>
> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1005.md
>
> All review-related feedback on and discussion of the DIP should occur in this thread. Due to DConf taking place during the review period, the period will be extended by a week. The review period will end at 11:59 PM ET on May 13 (3:59 AM GMT on May 14), or when I make a post declaring it complete.
>
> At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round. Otherwise, because the DIP comes from a language author and no formal review period by the language authors is necessary, the DIP will be marked "Accepted" or "Rejected" at the author's discretion.
>
> An extensive discussion regarding this DIP has already taken place [1].
>
> Thanks in advance to all who participate.
>
> Destroy!
>
> [1] http://forum.dlang.org/thread/o2psvk$1m96$1@digitalmars.com?page=1

I've said this before in the PR for the self important idiom, but I'll repeat my views on this here...

Aside from the exact syntax, this proposal is superior to the self important idiom that we all know is going to cause this DIP to be rejected in that it's more DRY. With the SII, you get stuff like

auto foo(from!"std.datetime".SysTime lhs, from!"std.datetime".SysTime rhs)
{
    ...
}

whereas with this DIP, you only have to list the import once. With the SII, you have to repeat the imports for every symbol whether they come from the same module or not or even if they're the same symbol. Also UFCS doesn't work with it, which can be problematic for template constraints. So, I think that the DIP is better than the SII (though IMHO, the issues with using "with" that have been brought up would need to be addressed for this DIP to be approved). The only advantage of SII is that we don't have to change the language to get it (which is very cool). But on the whole, SII is worse. However, regardless of whether this DIP or the self important idiom is better, I think that they're both going too far - at least if they're going to be pushed as best practice in any real way.

For a while now, We've been pushing for folks to use local imports and scoped imports as best practice, which does make sense on some level. You can look at a function and see which imports it uses, and it can reduce compile times - especially if you're using local and selective imports inside a template which may not even be instantiated. However, it makes for a _lot_ of extra code and is not at all DRY. Instead of simply putting the import at the top, you have to list it in every function that uses any symbol for it and list every single symbol from that module that you're using, which is tedious. And worse, as you write or refactor a function, you end up having to maintain that list of local and selective imports, changing them as the symbols that you use change. And after trying to do that as best practice for a while now, I'm sick of it. It's a maintenance nightmare. It's a lot of shuffling around of code for minimal benefit.

It is _so_ much nicer to be able to just slap the import at the top of the module and move on with life. You use whatever has been imported, and occasionally when you need a symbol that hasn't been imported, you add the import for that module, and you're doing _way_ less shuffling around of code. You also get shorter code, because you don't end up with all of those repeated imports (it's especially bad when the same symbols get used extensively throughout a module).

And we _already_ have a ridiculous number of attributes to stick on functions in D (on top of other stuff like template constaints), making it so that function signatures are often way too verbose. So, adding even more to the function signatures as would occur with this DIP or with the SII seems to me like it's going to far. Function signatures are getting too complicated, and IMHO, this DIP and SII simply don't pay for that extra complication.

The only real benefit I see from this DIP or the SII is the speed up in compilation time that can go with them, but that's just because it's effectively making some of the imports lazy - and Walter has already talked on multiple occasions about making imports lazy, which would then solve the problem, only better, because then you could just slap the import at the top of the module and have it be lazy rather than having to have all of this extra muck in your function signatures or having to have all of those local and selective imports. So, I'd like to see fully lazy imports be implemented like Walter has wanted to do and have that be the solution rather than marking up functions even further.

If folks want to do this stuff in their own code, then that's their prerogative, but I really don't want to see this sort of thing become "best practice." As it stands, I think that the local and selective imports are going to far. They take up too much space in the code and take too much time and effort to maintain to be worth it. And the only reason that this DIP ever came up was because of folks wanting to take local and selective imports even further instead of dialing them back, which is what I think we should be doing.

- Jonathan M Davis

On Friday, 12 May 2017 at 14:02:20 UTC, Jonathan M Davis wrote:
> On Saturday, April 22, 2017 11:54:08 Mike Parker via Digitalmars-d wrote:
>> DIP 1005 is titled "Dependency-Carrying Declarations".
>>
>> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1005.md
>>
>> All review-related feedback on and discussion of the DIP should occur in this thread. Due to DConf taking place during the review period, the period will be extended by a week. The review period will end at 11:59 PM ET on May 13 (3:59 AM GMT on May 14), or when I make a post declaring it complete.
>>
>> At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round. Otherwise, because the DIP comes from a language author and no formal review period by the language authors is necessary, the DIP will be marked "Accepted" or "Rejected" at the author's discretion.
>>
>> An extensive discussion regarding this DIP has already taken place [1].
>>
>> Thanks in advance to all who participate.
>>
>> Destroy!
>>
>> [1] http://forum.dlang.org/thread/o2psvk$1m96$1@digitalmars.com?page=1
>
> I've said this before in the PR for the self important idiom, but I'll repeat my views on this here...
>
> Aside from the exact syntax, this proposal is superior to the self important idiom that we all know is going to cause this DIP to be rejected in that it's more DRY. With the SII, you get stuff like
>
> auto foo(from!"std.datetime".SysTime lhs, from!"std.datetime".SysTime rhs)
> {
>     ...
> }
>
> whereas with this DIP, you only have to list the import once. With the SII, you have to repeat the imports for every symbol whether they come from the same module or not or even if they're the same symbol. Also UFCS doesn't work with it, which can be problematic for template constraints. So, I think that the DIP is better than the SII (though IMHO, the issues with using "with" that have been brought up would need to be addressed for this DIP to be approved). The only advantage of SII is that we don't have to change the language to get it (which is very cool). But on the whole, SII is worse. However, regardless of whether this DIP or the self important idiom is better, I think that they're both going too far - at least if they're going to be pushed as best practice in any real way.
>
> For a while now, We've been pushing for folks to use local imports and scoped imports as best practice, which does make sense on some level. You can look at a function and see which imports it uses, and it can reduce compile times - especially if you're using local and selective imports inside a template which may not even be instantiated. However, it makes for a _lot_ of extra code and is not at all DRY. Instead of simply putting the import at the top, you have to list it in every function that uses any symbol for it and list every single symbol from that module that you're using, which is tedious. And worse, as you write or refactor a function, you end up having to maintain that list of local and selective imports, changing them as the symbols that you use change. And after trying to do that as best practice for a while now, I'm sick of it. It's a maintenance nightmare. It's a lot of shuffling around of code for minimal benefit.
>
> It is _so_ much nicer to be able to just slap the import at the top of the module and move on with life. You use whatever has been imported, and occasionally when you need a symbol that hasn't been imported, you add the import for that module, and you're doing _way_ less shuffling around of code. You also get shorter code, because you don't end up with all of those repeated imports (it's especially bad when the same symbols get used extensively throughout a module).
>
> And we _already_ have a ridiculous number of attributes to stick on functions in D (on top of other stuff like template constaints), making it so that function signatures are often way too verbose. So, adding even more to the function signatures as would occur with this DIP or with the SII seems to me like it's going to far. Function signatures are getting too complicated, and IMHO, this DIP and SII simply don't pay for that extra complication.
>
> The only real benefit I see from this DIP or the SII is the speed up in compilation time that can go with them, but that's just because it's effectively making some of the imports lazy - and Walter has already talked on multiple occasions about making imports lazy, which would then solve the problem, only better, because then you could just slap the import at the top of the module and have it be lazy rather than having to have all of this extra muck in your function signatures or having to have all of those local and selective imports. So, I'd like to see fully lazy imports be implemented like Walter has wanted to do and have that be the solution rather than marking up functions even further.
>
> If folks want to do this stuff in their own code, then that's their prerogative, but I really don't want to see this sort of thing become "best practice." As it stands, I think that the local and selective imports are going to far. They take up too much space in the code and take too much time and effort to maintain to be worth it. And the only reason that this DIP ever came up was because of folks wanting to take local and selective imports even further instead of dialing them back, which is what I think we should be doing.
>
> - Jonathan M Davis

I largely agree with you.  The main reason I mentioned the self-important workaround in this thread is because it was said to obviate this DIP; I don't like that approach either.  My preference all along has been to just use selective imports at module scope, ie the status quo.

In the thread first discussing this DIP, Andrei said:

"Overall, yes, local imports have been a success (really saving scalability of large project builds which looked pretty bleak at a time), which should increase trust in the authors of the feature... hmmm... :o)"
http://forum.dlang.org/post/o4h0av$1rk2$1@digitalmars.com

I generally agreed with him about the success of local imports because it documents the code, as you say, but there is another better metric for success: is it used widely?  Take a random sample of projects on dub, and you find that it isn't used that much, so it's tough to call it an actual success yet.  I wonder who was doing those "large project builds," that are now extensively using local imports to compile faster.

As I noted to you on github, we need a tool that will automatically scope imports for us, otherwise I don't see local imports being used much, for the reasons you list.  I plan on working on such a tool to make it easy for us to use local imports.

Until then, my suggestion is that given the potential benefits of DCDs but limited actual use, we hold off on extending them further with this DIP or the self-important workaround.  Let's wait a year or so and see if a tool makes local imports much more common, to the point where people want to go further with either of these two DCD approaches.

There is nothing that requires us to do this now, it can wait.

On Saturday, 22 April 2017 at 11:54:08 UTC, Mike Parker wrote:
> DIP 1005 is titled "Dependency-Carrying Declarations".
>
> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1005.md
>
> All review-related feedback on and discussion of the DIP should occur in this thread. Due to DConf taking place during the review period, the period will be extended by a week. The review period will end at 11:59 PM ET on May 13 (3:59 AM GMT on May 14), or when I make a post declaring it complete.

The review is now closed. Thanks to all who participated.