[DIP] Resolution of Alias Template Parameters in Function Templates

jmh530 john.michael.hall at gmail.com
Sat May 18 16:05:10 UTC 2019


On Saturday, 18 May 2019 at 12:32:13 UTC, Stefanos Baziotis wrote:
> Here is a DIP that I've been working the last couple of days:
> https://github.com/baziotis/DIPs/blob/master/DIPs/DIP1021.md
>
> It is a proposal about how to handle alias templates when they 
> appear
> as parameters in function templates.
> It was initially proposed by Ilya here: 
> https://forum.dlang.org/post/kvcrsoqozrflxibgxtlo@forum.dlang.org
>
> as a GSoC project and then again by Seb as part of the 
> DataFrame project:
> https://forum.dlang.org/post/jyzgzxqgaggltgifwnxx@forum.dlang.org
>
> There are also a couple of Bugzilla reports, 2 of those 
> referenced in the DIP.
>
> I tried to make it as much of a scientific paper as possible, 
> but note that
> I don't have experience either in writing papers or DIPs.
>
> The DIP references a PR with a 3-day prototype implementation. 
> That was an initial
> implementation that I was working before identifying all the 
> corner cases of the feature.
> And the corner cases make it such that probably a lot of time 
> has to be spent
> for this feature to be fully supported. I believe however that 
> it might come in handy
> as it handles a lot of the Slice cases, which are the primal 
> motivation behind this.
> This is not my main GSoC project so I won't have to work on 
> that on the summer, but if anyone wants to work on it, please 
> keep me posted.
> The DIP also references an article that explains the problem in 
> a more informal fashion style.
> I'm planning to change this article to be more 
> implementation-specific where I will analyze
> the most important problems of implementing this fully.
>
> Best,
> Stefanos

Thanks for working on this.

You might remove the line
"People seem to pay money for this feature to be implemented."
While people (like Ilya and me) are willing to pay for this, it's 
not really relevant to the technical issues.

Also, the forum has been discussing recently using static ifs 
within a function instead of function overloads. I think the same 
argument applies here. For instance, if switching to the 
commented code, then the writeln("here") will get skipped for 
writeln("there"). Correspondingly, I think it would be nice for 
the DIP to also discuss resolving is expressions as well.

struct Slice(T) {
}

struct StairsIterator(T, string direction) {
}

alias PackedUpperTriangularMatrix(T) = Slice!(StairsIterator!(T*, 
"-"));

auto foo(T)(T m)
{
     import std.stdio : writeln;

     static if (is(T : Slice!(StairsIterator!(U*, "-")), U)) {
     //static if (is(T : PackedUpperTriangularMatrix!U, U)) {
         writeln("here");
     } else static if (is(T : Slice!U, U)) {
         writeln("there");
     } else {
         static assert(0, "should not be here");
     }
}

void main()
{
     Slice!int x;
     PackedUpperTriangularMatrix!int y;
     foo(x);
     foo(y);

     import std.stdio : writeln;
     writeln(is(typeof(y) : PackedUpperTriangularMatrix!U, U)); 
//prints false
     writeln(is(typeof(y) : Slice!(StairsIterator!(U*, "-")), U)); 
//prints true
}


More information about the Digitalmars-d mailing list