On Tuesday, 3 January 2017 at 20:07:59 UTC, Andrei Alexandrescu
wrote:
Arguing that local imports have been successful so we should
simply do
more of it is not a good argument, as there comes a point of
diminishing
returns. You need to show that there are still worthile gains
to be
made from changing the language again, which is why I want to
benchmark
this feature with Walter before deciding.
You can be reasonably certain the benchmarks will improve as
projected - starting in proportion to the the transitive fanout
of top-level imports (10.5x for the standard library) and going
down thereafter with the size, complexity, and actual
dependencies of the module being compiled. All in all
measurable but not dramatic. The same improvement will be
brought about by lazy imports, and it won't be the deal
maker/breaker. If you're waiting for the numbers to get
convinced of anything, you already consider DIP1005 useless.
I don't need dramatic, a solid win is fine. A small 10% or less
improvement in the speed of the import phase of compilation
probably isn't worth it.
Rather, the
argument is that local imports mostly solved this problem, so
why bother
adding new syntax for the dozen remaining symbols from 2-3
modules that
are commonly used in template constraints?
I understand. It is my humble opinion that we are "mostly
pregnant" for as long as we require top-level imports. The real
change of phase occurs when there are ZERO imports at top
level. That's the prize DIP1005 is after.
If you believe the benchmarks won't be dramatically different, I
wonder why you think there will be a phase change.
In the end, this is a minor DIP that is easily bikeshedded, as
everybody
can grasp it and have an opinion on it. I have refrained from
commenting recently because I will let benchmarking settle it
for me.
Obviously, that won't suffice for others.
I do agree that if framed as a modest improvement in build
economics, it is quite unimportant. But that's a problem with
the DIP; its main strength is better encapsulation, which is no
small thing.
Encapsulation is not an end in itself. You have listed four main
advantages of this change in the DIP. I have noted that I don't
find the first three relating to reasoning and refactoring worth
adding syntax for, while admitting that may be subjective. The
fourth talks about scalability, which I interpreted as either
compilation speed or some other measurable gain, hence my asking
for benchmarks.
If scalability refers to something else- it can't be reasoning or
refactoring as those are listed as separate advantages- I'd like
to hear what it is. If it's measurable, I'd like to measure it
first.
