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.
