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

[Jacob Carlborg via Digitalmars-d]

On 2017-07-10 19:54, Nick Sabalausky (Abscissa) wrote:

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

I agree, it's not me that need convincing :)

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

Here I disagree. I think that D should have something like this.

-- 
/Jacob Carlborg