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

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 07/10/2017 07:32 AM, Jacob Carlborg wrote:
> 
> Something like this has been proposed several times before, but Andrei 
> doesn't seem to like it. He think it's a failure that all the conditions 
> need to have a name, or something like that. I prefer your approach.
> 

Well, the nice thing about this approach (basing a concept-ish system 
*on top* of existing D-style design-by-introspection, as opposed to a 
C++-like concepts with no D-like features to complement it), is that it 
*doesn't* require every little variation to be named.

For example, in the same psuedo-code I posted, there's a function (the 
last join() overload) that takes an input range, but requires the input 
range to support hasLength. But notice that there is NO symbol created 
or used anywhere for InputRangeWithLength. IIUC, it sounds like C++ 
concepts would require such a symbol to be created. But with this, that 
would not be needed.

One thing to keep in mind is that we're ALREADY creating names for many 
(not all, but definitely some) of these things. In effect, *every* time 
we have an 'isXXXXX' function (isSomeString, isForwardRange, etc), we're 
already creating a name for it. We already implicitly understand that 
just because it's unrealisting to name *everything* (which, 
indicentally, reminds me of old Java class hierarchies), doesn't mean we 
can't or shouldn't name some things.

The other important thing I want to emplasize yet again (just in case, 
because I know from experience in the past it's exactly this kind of 
point that rarely gets noticed), I'm not proposing D do this. It'd be 
far too big a change and it's far too incomplete to even think of trying 
to push. (Even tiny straightforward improvements to D face dowwnright 
epic levels of resistance any more.) So again, it's just some 
brainstorming. Maybe D several decades from now, maybe some other 
language inspired by D, maybe nothing ever, whatever.