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

Meta via Digitalmars-d digitalmars-d at puremagic.com
Sun Jul 9 13:42:39 PDT 2017


On Sunday, 9 July 2017 at 20:22:16 UTC, Nick Sabalausky 
(Abscissa) wrote:
> On 07/09/2017 09:26 AM, Adam D. Ruppe wrote:
> > On Sunday, 9 July 2017 at 12:56:55 UTC, FoxyBrown wrote:
> >> return str.join(" ");
> >> [...]
> >> Error: template std.array.join cannot deduce function from
> argument
> >> types !()(string, string)
> >> [...]
> >> simply trying to join a string[] with a separator.
> >
> > The error message sucks, but you clearly have a string when
> you meant
> > string[].
>
> Related to this, I've been giving some thought lately to a 
> little bit of re-designing types themselves. Specifically, type 
> creation tools that go beyond what structs and classes give us 
> and allow better handling D-style generics.
>
> It's all very incomplete right now, but basically here's the 
> gist:
>
> Awesome as D's generics, ranges, etc all are, they do make two 
> things far more convoluted than when using basic 
> straightforward types: Function declarations, and error 
> messages when things don't match.
>
> 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.

I'm sorry if I misunderstood what you're proposing, but isn't 
this exactly what C++ set out to do with concepts? If that's the 
case, I'd recommend you look up some of Andrei's refutation of 
concepts in favour of template guards and `static if`.




More information about the Digitalmars-d mailing list