www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DIP 1005 - Preliminary Review Round 1

reply Mike Parker <aldacron gmail.com> writes:
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
Apr 22 2017
next sibling parent 9il <ilyayaroshenko gmail.com> writes:
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


Oh, this is huge, great work! Many thanks to all authors! --Ilya
Apr 22 2017
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On Saturday, 22 April 2017 at 11:54:08 UTC, Mike Parker wrote:

 https://github.com/dlang/DIPs/blob/master/DIPs/DIP1005.md



 with (Type) and with (TemplateInstance) are always declarations 
 and do not introduce a new scope.


Does that mean we can now do things like this?:

-----
module m;
struct A { struct B { } }
with (A) B b;
-----

That's a pretty cool addition.
Apr 22 2017
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 22.04.2017 17:16, Andrej Mitrovic wrote:

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

 https://github.com/dlang/DIPs/blob/master/DIPs/DIP1005.md



 with (Type) and with (TemplateInstance) are always declarations and do
 not introduce a new scope.


 Does that mean we can now do things like this?:

 -----
 module m;
 struct A { struct B { } }
 with (A) B b;
 -----

 That's a pretty cool addition.


With the current wording of the DIP, this will not work in local scopes. 
Why do we need more features for declaring global variables?
Apr 22 2017
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 22.04.2017 18:17, Timon Gehr wrote:

 On 22.04.2017 17:16, Andrej Mitrovic wrote:

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

 https://github.com/dlang/DIPs/blob/master/DIPs/DIP1005.md



 with (Type) and with (TemplateInstance) are always declarations and do
 not introduce a new scope.


 Does that mean we can now do things like this?:

 -----
 module m;
 struct A { struct B { } }
 with (A) B b;
 -----

 That's a pretty cool addition.


 With the current wording of the DIP, this will not work in local scopes.
 Why do we need more features for declaring global variables?


Correction: It will not work in function scopes.
Apr 22 2017
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On Saturday, 22 April 2017 at 11:54:08 UTC, Mike Parker wrote:

 https://github.com/dlang/DIPs/blob/master/DIPs/DIP1005.md


Very solid DIP! And I like the use of `with` and it's proposed 
extension to be allowed in declarations, rather than introducing 
new syntax.
Apr 22 2017
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 22.04.2017 17:31, Andrej Mitrovic wrote:

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

 https://github.com/dlang/DIPs/blob/master/DIPs/DIP1005.md


 Very solid DIP! And I like the use of `with` and it's proposed extension
 to be allowed in declarations, rather than introducing new syntax.


Please reconsider. This is new syntax. It looks like old syntax but 
behaves differently.
Apr 22 2017
parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On Saturday, 22 April 2017 at 16:14:29 UTC, Timon Gehr wrote:

 Please reconsider. This is new syntax. It looks like old syntax 
 but behaves differently.


I suppose the biggest issue is:

-----
module mod;
import std.stdio;

struct A
{
     ~this ( ) { writeln("dtor"); }
}
-----

-----
module test;

class C
{
     with (import mod) A a;  // declaration, lives as long as C 
lives

     void test ( )
     {
         with (import mod)  // statement
         {
             A a; // destroyed on exit of scope
         }

         // a was destroyed, and is not even visible here
     }
}
-----

I can see how this can be a pain point. If it's a big worry then 
I'd be ok with using one of the syntactic alternatives, like 
'import (std.stdio);'.
Apr 22 2017
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 22.04.2017 13:54, 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.

 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



"* Inside any function, all uses of with are statements and obey the 
current language rules.

* Everywhere else, ..."


"* Inside any function, with (Import ImportList) is a statement that 
introduces a scope. Inside the with, lookup considers the import local 
to the declaration (similar to the current handling of nested imports).

* Everywhere else, ..."


Please don't do this.



"This extension removes an unforced limitation of the current with 
syntax (allows it to occur at top level)"

No, it does not. It introduces two more incompatible syntaxes that look 
the same, yet are different.



"The drawback of this choice is the potentially confusing handling of 
scopes: the with statement introduces a scope, whereas the with 
declaration does not."

It's not merely confusing, it's frustrating. I might legitimately want 
to use the new feature on a local declaration. As an analogy, just 
imagine how frustrating it would be if 'static if' was written as 'if' 
with different meaning depending on the scope.



Just associate actual syntax to the the scope handling. The proposal 
would be sane if it instead introduced a new 'static with' construct 
that actually has the same meaning in every context.

This is how it works for static if, and it is also how it will work for 
static foreach, so it is even consistent with other language features.
Apr 22 2017
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Saturday, 22 April 2017 at 16:13:20 UTC, Timon Gehr wrote:

 This is how it works for static if, and it is also how it will 
 work for static foreach, so it is even consistent with other 
 language features.


So you will touch up your static foreach DIP ?
If so I am okay with building the implementation.
Apr 22 2017
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 22.04.2017 18:25, Stefan Koch wrote:

 On Saturday, 22 April 2017 at 16:13:20 UTC, Timon Gehr wrote:

 This is how it works for static if, and it is also how it will work
 for static foreach, so it is even consistent with other language
 features.


 So you will touch up your static foreach DIP ?
 If so I am okay with building the implementation.


Sounds good. Let's discuss this at DConf.
Apr 22 2017
prev sibling next sibling parent reply Joakim <dlang joakim.fea.st> writes:
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.

 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 thought this DIP was invalidated by the self-important 
workaround?

http://forum.dlang.org/post/o72kq8$ggc$1 digitalmars.com

https://github.com/dlang/druntime/pull/1756#issuecomment-277463742

Why is this still up for review?
Apr 22 2017
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/22/17 4:52 PM, Joakim wrote:

 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.

 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 thought this DIP was invalidated by the self-important workaround?
 
 http://forum.dlang.org/post/o72kq8$ggc$1 digitalmars.com
 
 https://github.com/dlang/druntime/pull/1756#issuecomment-277463742
 
 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.


Thanks,

Andrei
Apr 23 2017
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On Sunday, 23 April 2017 at 12:03:47 UTC, Andrei Alexandrescu 
wrote:

 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.


Wouldn't there be a compile-time performance impact from 
instantiating so many templates, virtually for every parameter 
who's type is defined in another module?
Apr 23 2017
parent reply deadalnix <deadalnix gmail.com> writes:
On Sunday, 23 April 2017 at 12:34:34 UTC, Andrej Mitrovic wrote:

 On Sunday, 23 April 2017 at 12:03:47 UTC, Andrei Alexandrescu 
 wrote:

 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.


 Wouldn't there be a compile-time performance impact from 
 instantiating so many templates, virtually for every parameter 
 who's type is defined in another module?


It's just one per module. Templates are only instantiated once 
per new set of arguments. There may be some gain here, but I 
doubt this is worth adding a new language feature.
Apr 23 2017
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On Sunday, 23 April 2017 at 16:39:35 UTC, deadalnix wrote:

 It's just one per module. Templates are only instantiated once 
 per new set of arguments. There may be some gain here, but I 
 doubt this is worth adding a new language feature.


Ah, good point.

Though there's still merit to this DIP such as this:


 With this syntax, the import is executed only if the declared 
 name (process) is actually looked up.


I don't believe the workaround with the `from` template fixes 
this.
Apr 23 2017
parent deadalnix <deadalnix gmail.com> writes:
On Sunday, 23 April 2017 at 19:25:09 UTC, Andrej Mitrovic wrote:

 With this syntax, the import is executed only if the declared 
 name (process) is actually looked up.


 I don't believe the workaround with the `from` template fixes 
 this.


Not sure what DMD does, but SDC sure would do it only if used.
Apr 23 2017
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2017-04-23 14:03, Andrei Alexandrescu wrote:


 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.


Absolutely, that's great. But I would have thought that the DIP would 
get retracted by the author, or do you still want to see this in the 
language?

-- 
/Jacob Carlborg
Apr 23 2017
prev sibling next sibling parent Arturg <var.spool.mail700 gmail.com> writes:
On Sunday, 23 April 2017 at 12:03:47 UTC, Andrei Alexandrescu 
wrote:

 On 4/22/17 4:52 PM, Joakim wrote:

 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.

 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 thought this DIP was invalidated by the self-important 
 workaround?
 
 http://forum.dlang.org/post/o72kq8$ggc$1 digitalmars.com
 
 https://github.com/dlang/druntime/pull/1756#issuecomment-277463742
 
 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.


 Thanks,

 Andrei


this example doenst work with the from!"modName" template, would 
it work with dip1005?

module moda;

struct Foo{int i;}

module modb;

void fun(from!"moda".Foo){}

module app;

template test(alias f)
{
     mixin("void test(" ~ 
from!"std.traits".Parameters!f.stringof[1..$-1] ~ "){}");
}

void main()
{
     import moda, modb;
     test!fun(Foo(5));
}

could dip1005 be introspected?

// you can make the above work with this or is there a better way?
template test(alias f)
{
     import traits;
     enum paramImports =
     {
string res;
         foreach(p; Parameters!f)
         {
            static if(!isBuiltinType!p) res ~= "import " ~ 
moduleName!p ~ ";\n";
         }
         return res;
     }();

     mixin(paramImports);
     mixin("void test(" ~ Parameters!f.stringof[1..$-1] ~ "){}");
}
Apr 23 2017
prev sibling parent Jon Degenhardt <jond noreply.com> writes:
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
Apr 23 2017
prev sibling next sibling parent deadalnix <deadalnix gmail.com> writes:
On Saturday, 22 April 2017 at 11:54:08 UTC, Mike Parker wrote:

 Destroy!


I'm not per se against going there but there are 2 points that 
needs to be considered. The first one is the "self important 
lookup" which obviate the need for this DIP to some extent.

Second, if we are going to proceed anyway, the way this is 
specified is not ideal. This DIP effectively adds 2 features:
1/ The ability to use import foo as an argument to a with 
statement.
2/ The introducing of a with declaration in addition of a with 
statement.

These two addition are independents as far as the spec goes and 
should be kept as such as to avoid an explosion of ad hoc 
solutions for the use case we want to enable, rather than 
providing building blocks that combine nicely to build such 
solutions.
Apr 23 2017
prev sibling next sibling parent reply Mike Parker <aldacron gmail.com> writes:
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.
May 06 2017
parent Mike Parker <aldacron gmail.com> writes:
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.
May 06 2017
prev sibling next sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
May 12 2017
parent Joakim <dlang joakim.fea.st> writes:
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.
May 12 2017
prev sibling parent Mike Parker <aldacron gmail.com> writes:
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.
May 13 2017