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

[Nick Sabalausky (Abscissa) via Digitalmars-d]

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.

Thought could also be put into additional type-creation tools that cater 
specifically to common things (again, such as ranges) to help streamline 
the process of creating them (ranges are awesome, but let's face it, 
defining them can be a bother - there's gotta be some way to make it 
simpler. For example, input ranges especially would GREATLY benefit from 
being definable in the mannar of C# stackless coroutines).

And of course, Nemerle-like (ML/Haskell-inspired) algebraics would be a 
wonderful capability to encorporate as well.

Another area to explore would be merging the two sets of parameter lists 
(the compile-time list and the run-time list) into one list. Certain 
types would be known to imply "compile-time". A keyword/attr could be 
used to force compile-time or runtime. And for other params, a 
sufficiently-smart compiler could conceivably even choose "runtime" vs 
"compile-time" (or even, "it varies") based on optimization priorities. 
It would simplify the syntax for users, and help get around fear of 
templates.

Obviously this is all very incomplete, but it's an idea I think is 
rather interesting.