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

[Andrei Alexandrescu via Digitalmars-d]

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