DIP 1005 - Preliminary Review Round 1

[Jonathan M Davis via Digitalmars-d]

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