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
+1
I understand the motivation for the proposal but I think that
good practice with package/module organisation renders the
benefits marginal. The flipside of that is that introducing this
new syntax reduces the pressure on people to organise their code
sensibly.
Is it a feature I'd like to be able to use when I'm writing: yes
Is it a feature I actually want to see in D and in the D
codebases I read daily: probably no, meh
Is it worth the time and effort of core developers and community
reviewers, both now and as an ongoing feature-maintenance burden:
absolutely not. I have no idea why this proposal is a priority
right now.