On 12/23/2016 05:33 PM, Chris Wright wrote:
On Fri, 23 Dec 2016 11:25:41 -0500, Andrei Alexandrescu wrote:
Dependency-Carrying Declarations allow scalable template libraries.
template libraries
*This* is the part I hadn't noticed before, and it explains the confusion
I had.
If you *only* apply this to templates, it works. The current situation is
a result of where template constraints are located. If there were a
`static throw` equivalent for indicating that parameters were invalid, or
if template constraints were in an `in` block like contracts, then this
wouldn't even have come up. If phobos went for object oriented code
instead of templates (as an example, not a recommendation), then this
wouldn't be an issue.
I acknowledge that if the language were defined a different way this
issue wouldn't have come up. But this is a truism - one can say that
about any issue.
However, at that point, it would be utterly useless to me. I'm looking at
my entire dub package cache, plus the ten-ish most recently updated dub
packages:
* units-d uses allSatisfy. Once.
* vibe has two structs that would benefit, except they're inside a
unittest. I've never compiled dub's unittests.
Fair enough. I reckon a number of traditional ways of designing software
would not be helped radically by DIP1005.
Template constraints have little adoption outside phobos.
That will change. We definitely need to do all we can to support and
improve language support for template constraints.
When they *are*
used, they tend to use language facilities instead of templates to
express the condition. And when a template is used, it tends to be
defined in the same module where it's used.
That may be true for some code today but not for future code. std.traits
gets larger and better with more interesting introspection capabilities.
I envision introspection as a core differentiating feature of D that
will put it ahead of all other languages.
I grant that everyone uses phobos, and phobos uses template constraints a
lot. If it's *just* a problem inside phobos, though, there's another
obvious solution: split up modules that tend to house a lot of template
constraints. Split up the modules that use a wide variety of template
constraints.
This point is discussed carefully in DIP1005. Please let me know if
anything needs to be added.
Now, if you want to apply this to things that are *not* templates, then
you could get a lot further. However, you would end up with code that
compiles when it wouldn't today. Code that compiles because the portions
you use would compile if they were on their own, while other bits
wouldn't. That's the status quo for templates, even no-arg templates, but
a change from what we currently do everywhere else.
And *that* is what would make it equivalent to use static or selective
imports. It would also increase the utility from my perspective from "why
the hell are we even doing this?" to "that's kinda nice".
Lazier compilation is indeed a projected benefit of this DIP. I did not
want to dilute the thrust of the proposal with a remote promise.
Andrei
