Types: The Next Generation (Was: Why is phobos so wack?)

[Mark via Digitalmars-d]

On Sunday, 9 July 2017 at 20:22:16 UTC, Nick Sabalausky 
(Abscissa) wrote:
> So, why not encapsulate much of that stuff we merely *describe* 
> in signatures for generic functions into genuine 
> honest-to-goodness types?
>
> There would be user-defined symbols, such as "InputRange" or 
> "SomeString", or "RandomAccessRange!SomeString", which the type 
> system sees as actual types. And naturally there would be some 
> mechanism for actually defining those types. Then, defining a 
> function like this:
>
> SomeString fizzbar(RandomAccessRange!SomeNumeric r) {...}
>
> ...would automatically imply to the compiler all (or at least a 
> lot of) the pluming we usually clutter the function declaration 
> with: Defining the templated types and calling the appropriate 
> if(isBlahBlah) constraints. About the only things remaining 
> would be additional constraints not already defined by the 
> next-gen types, and restrictions on how the parameters relate 
> to each other.
>
> Even better, having all that encapsulated into genuine types 
> should make it easier for the compiler to provide better error 
> messages.

This reminds me of the "RAII vs. scope" arguments that came up on 
the forum a few times (see e.g. [1]). Many of the features in D 
(and other programming languages) can be theoretically (and 
practically, in some languages) implemented using the type 
system: resource management, template constraints, in/out 
contracts, function attributes (pure, nothrow, etc.), I/O 
streams, error handling, and probably others. This is sometimes 
profitable and sometimes not so much.

If you're using some concept all over your code then 
encapsulating it in a type can reduce code duplication, improve 
readability and let you exploit various features of the type 
system to your benefit (e.g. subtyping: A RandomAccessRange being 
a subtype of InputRange, exception hierarchies, etc.). But if 
you're only using it once or twice then it's probably not worth 
the hassle. That is, the issue is scale.

My general impression is that C++ tries (and often succeeds, 
pyrrhically) to do pretty much everything using the type system 
(specifically, classes): Resources, exceptions, iterators, 
interfaces, initialization lists, ... Almost everything is 
encapsulated in a type. Concepts (Lite) seem to me like a way to 
further enrich the type system, although concepts aren't exactly 
types.

My opinion, in a nutshell, is that "ad-hocish" facilities like 
template constraints, the scope statement, contracts, etc. don't 
scale up, while more formal facilities like concepts, RAII, etc. 
don't scale *down*. As such, there is a need for both of them.

With respect to the specific issue of ranges, I don't know Phobos 
well enough to have an opinion as to whether or not they should 
be made more formal (as types/concepts/...). The error messages 
should be more clear and precise, but I'm not convinced that an 
overhaul of the system is necessary to achieve that.

[1] 
https://forum.dlang.org/post/tlsrpqvfeepcfbyfqzge@forum.dlang.org