On Thursday, 1 October 2020 at 12:08:40 UTC, Ola Fosheim Grøstad wrote:
> 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.

I kept myself from that.
Because I know that AST macros are frowned upon.
(Although what Walter is recently talking about sounds more and more like them)
And because I want to make it easy to migrate from templates.
to static template emulation functions (stef) :)

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.

On Thursday, 1 October 2020 at 11:35:10 UTC, jmh530 wrote:
> On Thursday, 1 October 2020 at 09:54:25 UTC, Stefan Koch wrote:
>> [snip]
>
> 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);
> }
>

No you would not be able to write that.
Because type functions are not polymorphic.
I.E. you cannot declare a variable with a type alias.

type functions do a Type -> TypeObject conversion when you pass the types in.
inside the type function you get a "type-like" interface.
But it has lost everything that made it a type.
It has sizeof, alignof, stringof, tupleof, you can use __traits on it.
But it cannot be used as a type anymore.
Not inside a type-function anyway.

If you return a type or a type tuple from a type function, it becomes a regular type/type tuple again.

On Thursday, 1 October 2020 at 12:08:40 UTC, Ola Fosheim Grøstad wrote:
> 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,

«follow» (how did that typo happen?)

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).

On Thursday, 1 October 2020 at 08:57:12 UTC, Stefan Koch wrote:
> At those scales there is no difference in compile time.
> However there is a difference in file size.

Your assert(__ctfe) PR should fix this.

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.

On Thursday, 1 October 2020 at 12:39:45 UTC, Adam D. Ruppe wrote:
> On Thursday, 1 October 2020 at 08:57:12 UTC, Stefan Koch wrote:
>> At those scales there is no difference in compile time.
>> However there is a difference in file size.
>
> Your assert(__ctfe) PR should fix this.

Not sure ... not all of it.
0000000000000000 r _TMP0
0000000000000002 r _TMP1
0000000000000038 r _TMP10
000000000000003d r _TMP11
0000000000000042 r _TMP12
0000000000000048 r _TMP13
000000000000004e r _TMP14
0000000000000052 r _TMP15
0000000000000059 r _TMP16
000000000000005d r _TMP17
0000000000000062 r _TMP18
0000000000000067 r _TMP19
0000000000000008 r _TMP2
000000000000000f r _TMP3
0000000000000016 r _TMP4
000000000000001e r _TMP5
0000000000000023 r _TMP6
0000000000000029 r _TMP7
000000000000002f r _TMP8
0000000000000036 r _TMP9

I think those are string literals.
which the static foreach version generates.
Those won't go away, it's hard to proof they are not used within the current framework of dmd.

On Thursday, 1 October 2020 at 13:41:58 UTC, Stefan Koch wrote:
> I think those are string literals.
> which the static foreach version generates.
> Those won't go away, it's hard to proof they are not used within the current framework of dmd.

So use a linker that can remove unused symbols.

On Thu, Oct 01, 2020 at 12:27:23PM +0000, Stefan Koch via Digitalmars-d wrote: [...]
> type functions do a Type -> TypeObject conversion when you pass the
> types in.
> inside the type function you get a "type-like" interface.
> But it has lost everything that made it a type.
> It has sizeof, alignof, stringof, tupleof, you can use __traits on it.
> But it cannot be used as a type anymore.
> Not inside a type-function anyway.
> 
> If you return a type or a type tuple from a type function, it becomes a regular type/type tuple again.

Isn't this just the same thing as Andrei's reification / dereification, except redressed in terms of aliases?


T

-- 
MACINTOSH: Most Applications Crash, If Not, The Operating System Hangs

On Thursday, 1 October 2020 at 13:53:53 UTC, H. S. Teoh wrote:
> On Thu, Oct 01, 2020 at 12:27:23PM +0000, Stefan Koch via Digitalmars-d wrote: [...]
>> type functions do a Type -> TypeObject conversion when you pass the
>> types in.
>> inside the type function you get a "type-like" interface.
>> But it has lost everything that made it a type.
>> It has sizeof, alignof, stringof, tupleof, you can use __traits on it.
>> But it cannot be used as a type anymore.
>> Not inside a type-function anyway.
>> 
>> If you return a type or a type tuple from a type function, it becomes a regular type/type tuple again.
>
> Isn't this just the same thing as Andrei's reification / dereification, except redressed in terms of aliases?
>
>
> T

Well you just pose the question the other way around.

Isn't Andrei's thing just a copy of mine, except redressed in terms of templates?

Yes. But the object being implicit I can use compiler internals to extract the data I need on the fly.
No need to prebuild conversion tables and the like.
No need to define a struct in druntime.