On Tuesday, 12 May 2020 at 15:42:03 UTC, Stefan Koch wrote:
that we can pass to an alias template parameter.
>
> Which name does "Foo" have?

Any unique identifier that would distinguish it from other symbols and literals? Give it the name of Alias!"Foo"?

Currently, this fails:

static assert(__traits(isSame, Alias!"Foo", "Foo"));
Error: static assert:  __traits(isSame, "Foo", "Foo") is false

The language is desperately trying to do the right thing but fails.

> There is a good reason for separating Symbols and literals.

I think there is not, just as there is no good reason for separating built-in and user-defined types.

On Wednesday, 6 May 2020 at 11:58:36 UTC, Stefan Koch wrote:
> Hello Guys,
>
> After a bit of fiddling the following code (and only that because I need do partial evaluation of the semantic pass on the function body manually ...)
> Now works on the Talias branch
>
> string F(alias y)
> {
>     return y.stringof;
> }
> static assert(F!(ulong) == "ulong");
> static assert(F!(uint) == "uint");

Since type functions aren't templates, and they're functions, could UFCS be applied?

On Wednesday, 13 May 2020 at 02:00:37 UTC, Clueless wrote:
> On Wednesday, 6 May 2020 at 11:58:36 UTC, Stefan Koch wrote:
>> Hello Guys,
>>
>> After a bit of fiddling the following code (and only that because I need do partial evaluation of the semantic pass on the function body manually ...)
>> Now works on the Talias branch
>>
>> string F(alias y)
>> {
>>     return y.stringof;
>> }
>> static assert(F!(ulong) == "ulong");
>> static assert(F!(uint) == "uint");
>
> Since type functions aren't templates, and they're functions, could UFCS be applied?

Possibly depends on whether it introduces ambiguity.

On Sunday, 10 May 2020 at 08:39:42 UTC, Nick Treleaven wrote:
> bool anySatisfy(alias Tem, alias[] S)
> {
>     bool found;
>     alias E;
>     while (S.length)
>     {
>         E = S[0];
>         if (Tem!E)
>             return true;
>         S = S[1..$];
>     }
>     return false;
> }

I realized after posting that Tem!E can't work, because the type function must be compiled before evaluating E. Tem!E would be a constant expression, if it even compiles (e.g. passing E as a template alias parameter, not passing the value of E).

So as Stefan wrote, type functions are like CTFE functions (maybe a superset?).

On Wednesday, 13 May 2020 at 19:22:36 UTC, Nick Treleaven wrote:
> On Sunday, 10 May 2020 at 08:39:42 UTC, Nick Treleaven wrote:
>> bool anySatisfy(alias Tem, alias[] S)
>> {
>>     bool found;
>>     alias E;
>>     while (S.length)
>>     {
>>         E = S[0];
>>         if (Tem!E)
>>             return true;
>>         S = S[1..$];
>>     }
>>     return false;
>> }
>
> I realized after posting that Tem!E can't work, because the type function must be compiled before evaluating E. Tem!E would be a constant expression, if it even compiles (e.g. passing E as a template alias parameter, not passing the value of E).
>
> So as Stefan wrote, type functions are like CTFE functions (maybe a superset?).

Well E is defined at interpretation time.
So I _could_ deferr the template instance until the value of E is known.
But the whole purpose of type functions is to discourage the use of templates in cases in which they are not needed.
In cases where a template is needed type functions will be of little use.
(you can possibly use them to remove internal instances).

On 14.05.20 10:09, Stefan Koch wrote:
> 
> In cases where a template is needed type functions will be of little use.

This is just not true. Template instantiations can be the result of the type function. E.g., map a list of types of struct members to array types with those types as element types. And anything that can be the result of a type function can be an argument to a type function for further processing.

In general, it is vastly more often than not a bad idea to claim that feature A shouldn't work with feature B because nobody would want to combine them anyway.

On Wednesday, 6 May 2020 at 12:01:11 UTC, Stefan Koch wrote:
> On Wednesday, 6 May 2020 at 11:58:36 UTC, Stefan Koch wrote:
>> Now works on the Talias branch
>>
>
> https://github.com/dlang/dmd/compare/master...UplinkCoder:talias?expand=1
>
> As you can see the modifications aren't even that heavy.
> I am confident this will take significantly less time than re-implementing CTFE.
> Because it's a new feature and bugs can be fixed as they are discovered.

I've switched my development process, to targeting stable and keeping the new branch green all the time.
That way super-delays like what happend with newCTFE should be avoided.

On the new branch the following example will compile

```
auto getUDAs(alias T)
{
    return __traits(getAttributes, T);
    pragma(msg, typeof(return));
}
// we can't parse alias[];
alias alias_array = typeof(getUDAs(SerializeTag));
struct SerializeTag {}

struct TypeWithTags
{
    alias type;
    alias_array tags;
}

TypeWithTags typeWithTags(alias T)
{
    auto udas = __traits(getAttributes, T);
    return TypeWithTags(T, udas);
}

@SerializeTag struct  ThisIsAType  {}

alias x = ThisIsAType;
pragma(msg, typeWithTags(x));
// output TypeWithTags((ThisIsAType), [(SerializeTag)])
```

The branch is here (and should be green most of the time):
Note that you'll have to comment out the call to `preFunctionParameters`
in expressionsem.d : 4176.
That is not done by default because it breaks the tests which make sure that functions are not called with types.
(which is obivously what type functions want to do ;) )

On Tuesday, 19 May 2020 at 14:42:25 UTC, Stefan Koch wrote:
> The branch is here (and should be green most of the time):
Doh ... I have to actually link it :)
And I didn't mean branch I meant PR ;)
https://github.com/dlang/dmd/pull/11146

On Tuesday, 19 May 2020 at 14:48:31 UTC, Stefan Koch wrote:
> On Tuesday, 19 May 2020 at 14:42:25 UTC, Stefan Koch wrote:
>> The branch is here (and should be green most of the time):
> Doh ... I have to actually link it :)
> And I didn't mean branch I meant PR ;)
> https://github.com/dlang/dmd/pull/11146

This test now works with the GREEN branch
auto getUDAs(alias T)
{
    return __traits(getAttributes, T);
    pragma(msg, typeof(return));
}

// we can't parse alias[];
alias alias_array = typeof(getUDAs(SerializeTag));

struct SerializeTag {}
struct SuperTag {string s;}

struct TypeWithTags
{
    alias type;
    alias_array tags;
}


TypeWithTags typeWithTags(alias T)
{
    auto udas = __traits(getAttributes, T);
    return TypeWithTags(T, udas);
}

@SuperTag("Smoking Super Style") @SerializeTag @SuperTag("Super!")
struct  ThisIsAType  { double y; }

alias x = ThisIsAType;

pragma(msg, "typeWithTags: ", typeWithTags(x));
//output: TypeWithTags((ThisIsAType), [SuperTag("Smoking Super Style"), (SerializeTag), SuperTag("Super!")])

On Wednesday, 27 May 2020 at 12:56:32 UTC, Stefan Koch wrote:
> On Tuesday, 19 May 2020 at 14:48:31 UTC, Stefan Koch wrote:
>> [...]
>
> This test now works with the GREEN branch
> auto getUDAs(alias T)
> {
>     return __traits(getAttributes, T);
>     pragma(msg, typeof(return));
> }
>
> [...]

Nice! I guess it's slowly becoming time to write that DIP ;-)