TypeFunction example creatiing a conversion matrix

[Stefan Koch]

On Thursday, 1 October 2020 at 12:32:47 UTC, Ola Fosheim Grøstad 
wrote:
> On Thursday, 1 October 2020 at 12:17:59 UTC, Stefan Koch wrote:
>> I do honestly believe that type functions fix a bunch of our 
>> problems.
>> And with very little code change, compared to the power they 
>> have.
>
> Maybe you can do it in such a way that it later can be viewed 
> as syntactic sugar for an AST-interfacing mechanism. At least 
> something to think about.
>
> Also, when introducing new mechanisms a useful exercise can be 
> to try to find existing mechanisms that can be implemented with 
> it. If so then one can argue that the core language became 
> simpler with the addition (so in the long term the compiler can 
> be simplified also).

It's an argument.
But I would like to argue my actual use-case first.

This doesn't make the language any simpler internally.
But it does make some code that people write take a fourth of the 
code in the binary.
And we get around all the funky things that happen with template 
emission.
(It's horribly broken right now)

Type functions are a restricted sub language which tries to 
replace common templates, (which should not ever have been 
templates in the first place).
It does not go for internal orthogonality.
It goes for making a very common usage patterns (at least in all 
the big codebases I looked at, it common)
Both simpler, and more performant.

It's placed between templates and functions.
If the you use templates only to reason about types, you can now 
use a function and be sure it won't leave crap in your binary, if 
nothing else.

I don't see the current approaches being able to guarantee that.
But maybe I am wrong?

I also don't see D coming to a slim core. And frankly I don't see 
why it needs to.
D does not cater to purists, it caters to people who value choice 
and creativity.
At least as far as I see it.
At least that is who I am.