Hello,

Bugfix for the Issue 16486 [1] (originally [2]) is required for mir-algorithm types [3], [4].

For example, packed triangular matrix can be represented as

Slice!(Contiguous, [1], StairsIterator!(T*))
Slice!(Contiguous, [1], RetroIterator!(MapIterator!(StairsIterator!(RetroIterator!(T*)), retro)))

They are used in mir-lapack [5]. The bug fix also required for mir (Sparse, CompressedTensor), and for the future Dlang image library.

Workarounds aren't interesting.

200$  - bounty ( I can pay directly or transfer money to the Dlang Foundation )

Best Regards,
Ilya Yaroshenko

[1] https://issues.dlang.org/show_bug.cgi?id=16486
[2] https://issues.dlang.org/show_bug.cgi?id=16465
[3] http://docs.algorithm.dlang.io/latest/mir_ndslice_slice.html#Slice
[4] http://docs.algorithm.dlang.io/latest/mir_series.html#Series
[5] https://github.com/libmir/mir-lapack/blob/master/source/mir/lapack.d

On Friday, 30 March 2018 at 06:11:22 UTC, 9il wrote:
> Hello,
>
> Bugfix for the Issue 16486 [1] (originally [2]) is required for mir-algorithm types [3], [4].
>
> For example, packed triangular matrix can be represented as
>
> Slice!(Contiguous, [1], StairsIterator!(T*))
> Slice!(Contiguous, [1], RetroIterator!(MapIterator!(StairsIterator!(RetroIterator!(T*)), retro)))
>
> They are used in mir-lapack [5]. The bug fix also required for mir (Sparse, CompressedTensor), and for the future Dlang image library.
>
> Workarounds aren't interesting.
>
> 200$  - bounty ( I can pay directly or transfer money to the Dlang Foundation )
>
> Best Regards,
> Ilya Yaroshenko
>
> [1] https://issues.dlang.org/show_bug.cgi?id=16486
> [2] https://issues.dlang.org/show_bug.cgi?id=16465
> [3] http://docs.algorithm.dlang.io/latest/mir_ndslice_slice.html#Slice
> [4] http://docs.algorithm.dlang.io/latest/mir_series.html#Series
> [5] https://github.com/libmir/mir-lapack/blob/master/source/mir/lapack.d

Given the recent blog post on std.variant, it occurs to me that this enhancement would also make writing functions that take Option types much easier. I'm adopting some of the code from the blog post below:

import std.variant;

alias Null = typeof(null); //for convenience
alias Option(T) = Algebraic!(T, Null);

Option!size_t indexOf(int[] haystack, int needle) {
    foreach (size_t i, int n; haystack)
        if (n == needle)
            return Option!size_t(i);
    return Option!size_t(null);
}

auto foo(T)(VariantN!(T.sizeof, T, typeof(null)) x)
{
    return x;
}

auto bar(T : Option!U, U)(T x)
{
    return x;
}

auto baz(T)(Option!T x)
{
    return x;
}

void main()
{
    import std.stdio : writeln;

    int[] a = [4, 2, 210, 42, 7];
    Option!size_t index = a.indexOf(42);

    writeln(index.foo!size_t); //works
    //writeln(index.foo); //doesn't work
    //writeln(index.bar); //doesn't work
    //writeln(index.baz); //doesn't work
}

On Friday, 30 March 2018 at 06:11:22 UTC, 9il wrote:
> [1] https://issues.dlang.org/show_bug.cgi?id=16486


Ah that is an interesting bug which further demonstrates that templates are a tricky thing :)
Basically you cannot _generally_ proof that one template just forwards to another.
Therefore you have to create separate types.
And since you create separate types the alias is not an alias but a separate template.
Solving this may be possible for special cases but in the general case is infeasible.

On 30.03.2018 08:11, 9il wrote:
> Hello,
> 
> Bugfix for the Issue 16486 [1] (originally [2]) is required for mir-algorithm types [3], [4].
> 
> For example, packed triangular matrix can be represented as
> 
> Slice!(Contiguous, [1], StairsIterator!(T*))
> Slice!(Contiguous, [1], RetroIterator!(MapIterator!(StairsIterator!(RetroIterator!(T*)), retro)))
> 
> They are used in mir-lapack [5]. The bug fix also required for mir (Sparse, CompressedTensor), and for the future Dlang image library.
> 
> Workarounds aren't interesting.
> 
> 200$  - bounty ( I can pay directly or transfer money to the Dlang Foundation )
> 
> Best Regards,
> Ilya Yaroshenko
> 
> [1] https://issues.dlang.org/show_bug.cgi?id=16486
> [2] https://issues.dlang.org/show_bug.cgi?id=16465
> [3] http://docs.algorithm.dlang.io/latest/mir_ndslice_slice.html#Slice
> [4] http://docs.algorithm.dlang.io/latest/mir_series.html#Series
> [5] https://github.com/libmir/mir-lapack/blob/master/source/mir/lapack.d

This is supported in https://github.com/tgehr/d-compiler
It has explicit "unknown" types and may instantiate templates using them during IFTI. The result is then matched against the argument types.

On Friday, 30 March 2018 at 13:56:45 UTC, Stefan Koch wrote:
> On Friday, 30 March 2018 at 06:11:22 UTC, 9il wrote:
>> [1] https://issues.dlang.org/show_bug.cgi?id=16486
>
>
> Ah that is an interesting bug which further demonstrates that templates are a tricky thing :)
> Basically you cannot _generally_ proof that one template just forwards to another.
> Therefore you have to create separate types.
> And since you create separate types the alias is not an alias but a separate template.
> Solving this may be possible for special cases but in the general case is infeasible.

What about something like this (using the reduced example from the bug report):

import std.traits : TemplateOf;

struct TestType(T) {}
alias TestAlias(T) = TestType!T;

template testFunction(T, alias U = TemplateOf!(TestAlias!T))
{
    void testFunction(U!T arg) {}
}

void main()
{
    TestAlias!int testObj;
    testFunction(testObj);
}

On Friday, 30 March 2018 at 15:21:26 UTC, jmh530 wrote:
> [snip]
>

Doesn't extend to multiple template parameters that well...

import std.traits : TemplateOf;

struct TestType(T, U) {}
alias TestAlias(T) = TestType!(T, int);

template testFunction(T, alias U = TemplateOf!(TestAlias!T))
{
    void testFunction(U!(T, int) arg) {} //don't want to have to put the int here
}

void main()
{
    TestAlias!int testObj;
    testFunction(testObj);
}

On Friday, 30 March 2018 at 06:11:22 UTC, 9il wrote:
> Hello,
>
> Bugfix for the Issue 16486 [1] (originally [2]) is required for mir-algorithm types [3], [4].
>
> For example, packed triangular matrix can be represented as
>
> Slice!(Contiguous, [1], StairsIterator!(T*))
> Slice!(Contiguous, [1], RetroIterator!(MapIterator!(StairsIterator!(RetroIterator!(T*)), retro)))
>
> They are used in mir-lapack [5]. The bug fix also required for mir (Sparse, CompressedTensor), and for the future Dlang image library.
>
> Workarounds aren't interesting.
>
> 200$  - bounty ( I can pay directly or transfer money to the Dlang Foundation )
>
> Best Regards,
> Ilya Yaroshenko
>
> [1] https://issues.dlang.org/show_bug.cgi?id=16486
> [2] https://issues.dlang.org/show_bug.cgi?id=16465
> [3] http://docs.algorithm.dlang.io/latest/mir_ndslice_slice.html#Slice
> [4] http://docs.algorithm.dlang.io/latest/mir_series.html#Series
> [5] https://github.com/libmir/mir-lapack/blob/master/source/mir/lapack.d

It's a feature request, according to the comments. So before anyone goes wasting their time implementing this. Someone might want to write the DIP for it.

On Friday, 30 March 2018 at 15:49:30 UTC, jmh530 wrote:
> On Friday, 30 March 2018 at 15:21:26 UTC, jmh530 wrote:
>> [snip]
>>
>
> Doesn't extend to multiple template parameters that well...
> [snip]

This works, but ugly...

template testFunction(T, U = TestAlias!T, alias V = TemplateOf!(U), W = TemplateArgsOf!U[1])
{
    void testFunction(V!(T, W) arg) {}
}

On Friday, 30 March 2018 at 13:56:45 UTC, Stefan Koch wrote:
> On Friday, 30 March 2018 at 06:11:22 UTC, 9il wrote:
>> [1] https://issues.dlang.org/show_bug.cgi?id=16486
>
>
> Solving this may be possible for special cases but in the general case is infeasible.

Can the case where the name of original template in scope of the alias template refers to an unique template template be implemented? It should be good enough for Mir and Phobos.

// There are unique defs for OriginalTemplate and ParamsMap
import lala : OriginalTemplate, ParamsMap;
alias AliasTemplate(SomeParams...) = OriginalTemplate!(ParamsMap!SomeParams);

On Friday, 30 March 2018 at 17:10:22 UTC, 9il wrote:
> On Friday, 30 March 2018 at 13:56:45 UTC, Stefan Koch wrote:
>> On Friday, 30 March 2018 at 06:11:22 UTC, 9il wrote:
>>> [1] https://issues.dlang.org/show_bug.cgi?id=16486
>>
>>
>> Solving this may be possible for special cases but in the general case is infeasible.
>
> Can the case where the name of original template in scope of the alias template refers to an unique template template be implemented? It should be good enough for Mir and Phobos.
>
> // There are unique defs for OriginalTemplate and ParamsMap
> import lala : OriginalTemplate, ParamsMap;
> alias AliasTemplate(SomeParams...) = OriginalTemplate!(ParamsMap!SomeParams);

Depends greatly on what ParamsMap does. Probably the simplest counterexample:

    alias ParamsMap(T...) = int;

So I have this instance of OriginalTemplate!int - did it come from an AliasTemplate!int? Maybe it was AliasTemplate!string, or AliasTemplate!(1,2,3,MyClass) - there's just no way to know.


Of course, that's an extreme example, but the fundamental requirement is that ParamsMap needs to be injective - each possible output would need to map to exactly one input. Also, this mapping must be possible to reverse-engineer.

If we are to support this, a DIP must be written to explain the algorithm to reverse the mapping. This is absolutely possible for a subset of cases, and would be a benefit in those cases. Of course we also run the risk of creating more confusing corner cases, and an influx of questions in D.learn of people asking 'why does X work, but not Y?'.

--
  Simen