On 2017-07-10 22:19, Nick Sabalausky (Abscissa) wrote:
> On 07/10/2017 04:14 PM, Nick Sabalausky (Abscissa) wrote:
>>
>> Oh, I didn't mean to imply that I wouldn't love to have it in D (assuming it was all well-fleshed out and didn't have big problems). I just wanted to be crystal clear that I'm merely discussing a langauge design idea here rather than coming in saying "Hey, you people should all like this idea and go implement it put it into D!!!" It's easy for things to get taken that way here, and can result in knee-jerk reactions and otherwise derailing of what's really only intended as a theoretical academic discussion. If something *were* to come of it, and it worked great, and everybody was happy, then fantastic. That's just not what I'm bringing it up for, that's all.
> 
> I especially wanted to avoid any the "How dare you even consider speaking of something without fully implementing it first!" that tends to be common here. (Speaking of, *that* sort of thing is far more unprofessional than the mere "bad words" some people are so terrified of).

Fair enough.

-- 
/Jacob Carlborg

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