module test;

struct MatrixImpl(S, size_t M, size_t N)
{
}

template Vector(S, size_t N)
{
    alias Vector = MatrixImpl!(S, 1, N);
}

@nogc
S dot1(S, size_t N)(in Vector!(S, N) lhs, in Vector!(S, N) rhs)
{
    return 0;
}

@nogc
S dot2(S, size_t N)(in MatrixImpl!(S, 1, N) lhs, in MatrixImpl!(S, 1, N) rhs)
{
    return 0;
}

unittest
{
    import std.stdio;

    Vector!(float, 2) a, b;
    dot1(a, b); // Error: none of the overloads of template `test.dot1` are callable using argument types `!()(MatrixImpl!(float, 1LU, 2LU), MatrixImpl!(float, 1LU, 2LU))`
                // Candidate is: `dot1(S, ulong N)(in Vector!(S, N) lhs, in Vector!(S, N) rhs)`
    dot2(a, b); // compiles
    static if (is(Vector!(float, 2) == MatrixImpl!(float, 1, 2)))
    {
        writeln("WTH"); // prints
    }
}

It's natural to declare it the way dot1 is declared, isn't it?
Is this a bug?
Or I simply can't assume alias works the way I thought it would.
Can I work around it, without falling back to the abominable dot2?

On Sunday, 1 May 2022 at 03:57:12 UTC, Elfstone wrote:

module test;

struct MatrixImpl(S, size_t M, size_t N)
{
}

AFAICT, I'm afraid you'll have to stick to dot2 🙁

This DIP I believe does what you want but... It wasn't looked upon favorably...

https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1023.md

On Sunday, 1 May 2022 at 06:42:26 UTC, Tejas wrote:

module test;

struct MatrixImpl(S, size_t M, size_t N)
{
}

Thanks a lot! So this really is a D "feature".
The current behaviour is so broken. It makes no sense, for a language user at least.
I don't understand why it's not yet solved, if it's a known issue.

On Sunday, 1 May 2022 at 07:59:57 UTC, Elfstone wrote:

module test;

struct MatrixImpl(S, size_t M, size_t N)
{
}

I guess the current best is something like:

enum isVector(V) = is(V==MatrixImpl!(S,1,N),S,size_t N);

@nogc
auto dot1(V)(in V lhs, in V rhs)
if(isVector!V) {
    return dot2(lhs,rhs);
}

or

enum isVector(V) = is(V==MatrixImpl!(S,1,N),S,size_t N);

@nogc
auto dot1(V)(in V lhs, in V rhs)
if(isVector!V) {
    static if(is(V==MatrixImpl!(S,1,N),S,N)) { S ret=0; return ret; }
    static assert("This should never been shown");
}

On Sunday, 1 May 2022 at 11:34:49 UTC, JG wrote:

enum isVector(V) = is(V==MatrixImpl!(S,1,N),S,size_t N);

@nogc
auto dot1(V)(in V lhs, in V rhs)
if(isVector!V) {
    return dot2(lhs,rhs);
}

enum isVector(V) = is(V==MatrixImpl!(S,1,N),S,size_t N);

@nogc
auto dot1(V)(in V lhs, in V rhs)
if(isVector!V) {
    static if(is(V==MatrixImpl!(S,1,N),S,N)) { S ret=0; return ret; }
    static assert("This should never been shown");
}

The static assert isn't needed.

enum isVector(V) = is(V==MatrixImpl!(S,1,N),S,size_t N);

@nogc
auto dot1(V)(in V lhs, in V rhs)
if(isVector!V) {
     static if(is(V==MatrixImpl!(S,1,N),S,N)) { S ret=0; return ret; }
}

On Sunday, 1 May 2022 at 11:37:28 UTC, JG wrote:

enum isVector(V) = is(V==MatrixImpl!(S,1,N),S,size_t N);

@nogc
auto dot1(V)(in V lhs, in V rhs)
if(isVector!V) {
     static if(is(V==MatrixImpl!(S,1,N),S,N)) { S ret=0; return ret; }
}

Great, I'm using the constraint, until it's fixed.
Will it be fixed though? The DIP that Tejas linked is from 2020!!!

On Sunday, 1 May 2022 at 12:39:08 UTC, Elfstone wrote:

The DIP was postponed. I can contact the author to see if he intends to pick it up again. If not, anyone interested can take it over. And anyone can submit an alternative at any time.

On Sunday, 1 May 2022 at 14:14:59 UTC, Mike Parker wrote:

Thanks. This breaks a lot of things. I don't know the reason behind the postponing, but who would expect one can't declare a parameter with an alias if it's a template?! Speaking of inconsistency.
I'm sure there are bigger issues out there to be solved, but it's quite disencouraging if such a significant improvement(or rather fix) stays ignored.

I just recently started investing my spare time in D, rewriting something I wrote in C++, because the first look at D was really nice. I ran into quite a few problems and have questioned the design here and there. Fortunately (and unfortunately), this so far is the biggest issue I've run into.
For now, I think I'll keep doing what I have being doing, hoping D will suit my purpose. Then I can invest more.

On Monday, 2 May 2022 at 00:54:40 UTC, Elfstone wrote:

At the bottom of the DIP you can find a link to the first community review round and a summary of the feedback. You'll see the DIP author decided he needed to do more work on the it.

Ultimately, he decided he didn't have a deep enough understanding to complete the DIP without some research, but he was too busy to make that investment. I suggested we mark it as postponed until he could come back to it. Reviewing our conversation, he was willing to someone else taking it over. So if anyone is willing, I don't need to wait on a response from him to make that happen.

Everyone rates issues differently. What's significant to one person won't be to another. There is much, much work to be done on shoring up holes in existing systems and solving problems the language maintainers believe to be significant, but resources are limited. So some things will inevitably be left to one side until someone picks them up.

For issues that are bugs or minor enhancements, we now have Razvan Nitu and Dennis Korpel in part-time positions funded by Symmetry Investments. They manage our issues database and our pull request queues. You can always ping one of them about any particular issue that doesn't require a DIP. This has been a huge change for the better. It means issues and PRs are much less likely to stagnate.

For something like your issue, which is a modification of the specification, a DIP is required. And that means either writing one or finding someone willing to write one and see it through to the end of the process. This isn't like managing bugs and pull requests. We simply don't have enough people on board to work on things like this. So it has to be done by interested parties in the community.

I wouldn't expect you to take over DIP 1023 yourself since you're new to the language, but if it's important enough to you, perhaps you can find someone to champion it, given a little time. Maybe the original author would be willing to pick it up again.

On Sunday, 1 May 2022 at 03:57:12 UTC, Elfstone wrote:

module test;

struct MatrixImpl(S, size_t M, size_t N)
{
}

template Vector(S, size_t N)
{
    alias Vector = MatrixImpl!(S, 1, N);
}

@nogc
S dot1(S, size_t N)(in Vector!(S, N) lhs, in Vector!(S, N) rhs)
{
    return 0;
}

@nogc
S dot2(S, size_t N)(in MatrixImpl!(S, 1, N) lhs, in MatrixImpl!(S, 1, N) rhs)
{
    return 0;
}

unittest
{
    import std.stdio;

    Vector!(float, 2) a, b;
    dot1(a, b); // Error: none of the overloads of template `test.dot1` are callable using argument types `!()(MatrixImpl!(float, 1LU, 2LU), MatrixImpl!(float, 1LU, 2LU))`
                // Candidate is: `dot1(S, ulong N)(in Vector!(S, N) lhs, in Vector!(S, N) rhs)`
    dot2(a, b); // compiles
    static if (is(Vector!(float, 2) == MatrixImpl!(float, 1, 2)))
    {
        writeln("WTH"); // prints
    }
}

Template deduction for aliased function parameter is a very tricky argument and it's not so simple to handle in certain cases. Consider for example this code:

    template MyAlias(T){
      alias MyAlias = int;
    }

    T simp(T)(MyAlias!T val){
      return T.init;
    }

    int main(){
      simp(3);//Impossible to deduce T
      simp( cast(MyAlias!string) 4);//Also invalid since MyAlias!string is exactly int
      simp!string(4);//Ok, no parameter deduction
    }

Instead to use aliases it's better (both in D and in C++) to use constraints/concepts.