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