On Thursday, 15 December 2016 at 22:56:42 UTC, Dmitry Olshansky
wrote:
On 12/13/16 11:33 PM, Andrei Alexandrescu wrote:
Destroy.
https://github.com/dlang/DIPs/pull/51/files
Andrei
On first it seems like an awesome idea. That solves ... but
wait what? Thinking more about the problem at hand - I fail to
see what this DIP accomplishes that can't be done better today.
1. The benefit of placing import to each function is based on
the untold assumption that we have:
a) huge modules with many functions
b) that constraints of these functions require different
(large) modules
The reality is far from this picture - if anything 99% of
template constraints are dependent on std.range.primitives and
std.traits with a bit of std.meta from time to time. So we'd
have a boilerplate of
auto foo(R)(R range)
(import std.range.primitives)
if(isInputRange!R){ ... }
everywhere for no noticeable benefit - touch one of functions
and you get full set of imports of these _small_ modules.
2. By itself the mechanism for delaying import even for
constraint until the function is touched is moot as long as the
module in question is huge and is not split in pieces. In other
words:
auto foo(R)(R range)
(import std.range)
if(isInputRange!R){ ... }
Pulls in full std.range the moment foo is touched, compared to
import std.range.primitives;
...
auto foo(R)(R range)
if(isInputRange!R){ ... }
which is because it actually isolates the whole mess of
complete std.range from the user of a template.
All in all my practical response is split the modules at least
in 2 parts: constraints + full functionality, then import the
one with constraints at the top level. Works today and solves
the practical issues unlike the proposal.
---
Dmitry Olshansky
I largely agree with Dmitry. Ilya refactored several Phobos
modules to use scoped, selective imports much more, and I pitched
in for some remaining imports in the largest modules, so that
only these module-level imports remain, ie those necessary for
symbols imported in template constraints:
std.datetime - https://github.com/dlang/phobos/pull/4373/files
std.uni - https://github.com/dlang/phobos/pull/4365/files
std.string and std.traits -
https://github.com/dlang/phobos/pull/4370/files
When I first saw this DIP, like Dmitry I was happy that we could
get rid of those too, but the more I see these horrible syntax
suggestions for what is really a minor convenience, I changed my
mind. std.datetime, the 35k line (17 kloc according to Dscanner)
beast of phobos, only needs 20 or so symbols at module-scope.
std.uni- 10k lines, 4.2 kloc- only needs 17 symbols, all from the
three modules Dmitry mentioned. I don't think his workaround of
splitting up modules is even needed for such a low amount of
module-level imports.
Maybe there are other issues having to do with symbol resolution
and dependency encapsulation that are addressed by this DIP, ie
the technical performance of the compiler rather than refactoring
or code clarity, that I don't fully grasp, but from the first two
points of the claimed benefits of DCDs, ie ease of reasoning
about dependencies and refactoring code, I don't think this
feature will come anywhere close to carrying its own weight.
As for the third benefit having to do with scalable template
libraries, I'm not sure I completely understand all the details
there, but I wonder if those problems aren't an artifact of the
way dmd works now rather than something that can't be fixed
without this DIP.
