On Thursday, 1 October 2020 at 09:37:20 UTC, user1234 wrote:
>
> BTW how is doing the DIP for this ;)

I have a start.
But right now my motivation to continue the DIP is quite low.
It seems Andrei and Walter are immersed in building a cargo-cult version of this.

On Thursday, 1 October 2020 at 09:44:42 UTC, Stefan Koch wrote:
> On Thursday, 1 October 2020 at 09:37:20 UTC, user1234 wrote:
>>
>> BTW how is doing the DIP for this ;)
>
> I have a start.
> But right now my motivation to continue the DIP is quite low.
> It seems Andrei and Walter are immersed in building a cargo-cult version of this.

That's sad. I start believing to TypeFunction, you see I'm not like those who's been immediatly enthusisast, but well, if the boss shortcut your work with workarounds (surface changes as you said yesterday) having them in D will be a problem, e.g "we can do that with... which already exist...bla bla"

On Thursday, 1 October 2020 at 09:52:19 UTC, user1234 wrote:
> On Thursday, 1 October 2020 at 09:44:42 UTC, Stefan Koch wrote:
>> On Thursday, 1 October 2020 at 09:37:20 UTC, user1234 wrote:
>>>
>>> BTW how is doing the DIP for this ;)
>>
>> I have a start.
>> But right now my motivation to continue the DIP is quite low.
>> It seems Andrei and Walter are immersed in building a cargo-cult version of this.
>
> That's sad. I start believing to TypeFunction, you see I'm not like those who's been immediatly enthusisast, but well, if the boss shortcut your work with workarounds (surface changes as you said yesterday) having them in D will be a problem, e.g "we can do that with... which already exist...bla bla"

I mean on the other hand.
Maybe I should be motivated.
Now I can do a direct comparison to alternative implementations.
Without having to write the alternative myself.

On Thursday, 1 October 2020 at 09:54:25 UTC, Stefan Koch wrote:
> On Thursday, 1 October 2020 at 09:52:19 UTC, user1234 wrote:
>> On Thursday, 1 October 2020 at 09:44:42 UTC, Stefan Koch wrote:
>>> On Thursday, 1 October 2020 at 09:37:20 UTC, user1234 wrote:
>>>>
>>>> BTW how is doing the DIP for this ;)
>>>
>>> I have a start.
>>> But right now my motivation to continue the DIP is quite low.
>>> It seems Andrei and Walter are immersed in building a cargo-cult version of this.
>>
>> That's sad. I start believing to TypeFunction, you see I'm not like those who's been immediatly enthusisast, but well, if the boss shortcut your work with workarounds (surface changes as you said yesterday) having them in D will be a problem, e.g "we can do that with... which already exist...bla bla"
>
> I mean on the other hand.
> Maybe I should be motivated.
> Now I can do a direct comparison to alternative implementations.
> Without having to write the alternative myself.

(note I leave the serious domain)

I'm amused actually by the alternative. It's a FFT that makes you travel from the type domain to the string domain and an iFFT that makes you travel from the string domain to the type domain if I have followed correctly.

On Thursday, 1 October 2020 at 10:10:47 UTC, user1234 wrote:
>
> (note I leave the serious domain)
>
> I'm amused actually by the alternative. It's a FFT that makes you travel from the type domain to the string domain and an iFFT that makes you travel from the string domain to the type domain if I have followed correctly.

Well it's is just kindof what happens.
They transform a type an Object representing the type.
which includes the mangle, which of course identifies the type uniquely.
Therefore you can go from TypeObject -> string -> Type
All of which has to be in template land of course.
Type -> TypeObject has to be done in a template there's no way around that.
And string -> Type has to be done in a template as well, and that string has to be a template parameter.
Therefore you still have to work within templates.

On Thursday, 1 October 2020 at 08:38:43 UTC, user1234 wrote:
> On Thursday, 1 October 2020 at 08:26:53 UTC, Stefan Koch wrote:
>> On Thursday, 1 October 2020 at 08:21:24 UTC, Stefan Koch wrote:
>>
>>> string makeConvMatrix(alias[] types ...)
>>
>> Wait .... What the Hell?
>> Why did this compile?
>>
>> I must have fixed parsing `alias[]` ?
>
> By the way why cant you pass directly the types (i.e lowercase builtins) ?

Is this something that could be changed theoretically (i.e. with a DIP)?

On Thursday, 1 October 2020 at 09:54:25 UTC, Stefan Koch wrote:
> [snip]
>
> I mean on the other hand.
> Maybe I should be motivated.
> Now I can do a direct comparison to alternative implementations.
> Without having to write the alternative myself.

I certainly think it's interesting and seems more straightforward than Andrei's reification example, but more concrete results will help your case. You might make a few examples of both simple and complex use cases of this technique and compare (at least compile-time and the size of object files) to the current D compiler and Andrei's reification approach. You might have a case if you can show quantitative improvements over the alternatives.

One thing that keeps coming to my mind when you are providing examples is the zig language's comptime [1]. They have the example of

fn max(comptime T: type, a: T, b: T) T {
    return if (a > b) a else b;
}
fn gimmeTheBiggerFloat(a: f32, b: f32) f32 {
    return max(f32, a, b);
}
fn gimmeTheBiggerInteger(a: u64, b: u64) u64 {
    return max(u64, a, b);
}

and obviously this could be done in D with templates. But if type functions were in D, then I would imagine you should also be able to do it like:

T max(alias T, T a, T b) {
    return (a > b) ? a : b;
}
float gimmeTheBiggerFloat(float a, float b) {
    return max(float, a, b);
}
uint gimmeTheBiggerInteger(uint a, uint b) {
    return max(uint, a, b);
}


[1] https://ziglang.org/documentation/master/#Introducing-the-Compile-Time-Concept

On Thursday, 1 October 2020 at 11:22:12 UTC, jmh530 wrote:
> On Thursday, 1 October 2020 at 08:38:43 UTC, user1234 wrote:
>> On Thursday, 1 October 2020 at 08:26:53 UTC, Stefan Koch wrote:
>>> On Thursday, 1 October 2020 at 08:21:24 UTC, Stefan Koch wrote:
>>>
>>>> string makeConvMatrix(alias[] types ...)
>>>
>>> Wait .... What the Hell?
>>> Why did this compile?
>>>
>>> I must have fixed parsing `alias[]` ?
>>
>> By the way why cant you pass directly the types (i.e lowercase builtins) ?
>
> Is this something that could be changed theoretically (i.e. with a DIP)?

Yes indeed.

On Thursday, 1 October 2020 at 09:52:19 UTC, user1234 wrote:
> That's sad. I start believing to TypeFunction, you see I'm not like those who's been immediatly enthusisast, but well, if the boss shortcut your work with workarounds (surface changes as

It is interesting to folly what Stefan is trying to achieve, introducing type variables is something I have argued for in the past.

Although, if you look at all the different discussions that take place over time, you might argue that a more comprehensive AST interface would solve more issues as language changes are being resisted quite heavily at this point.

On Thursday, 1 October 2020 at 10:16:47 UTC, Stefan Koch wrote:
> And string -> Type has to be done in a template as well, and that string has to be a template parameter.
> Therefore you still have to work within templates.

Is it possible to applying the `AliasSeq`-special-handling-hack in dmd to make `reify` and `unreify` not be real templates?

Would it be possible to rewrite often-used templates in druntime/phobos to use alias functions and highlight savings in compile-time/space and object-size for larger use cases?