DIP10005: Dependency-Carrying Declarations is now available for community feedback

[Chris Wright via Digitalmars-d]

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.

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.

Template constraints have little adoption outside phobos. 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.

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.

Then I can decide whether the convenience of not hunting for narrower 
imports is worth the extra quarter second of compilation.

----

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".