On Wednesday, 23 December 2020 at 17:08:26 UTC, 9il wrote:
> https://issues.dlang.org/show_bug.cgi?id=16486
> https://issues.dlang.org/show_bug.cgi?id=16465
> https://issues.dlang.org/show_bug.cgi?id=10884
> and the oldest one reported in 2008
> https://issues.dlang.org/show_bug.cgi?id=1807
>
> C++ templates can be resolved, at least at the level Mir needs this. So, it is a bug in my opinion. But it was said the DIP is required. I can't write DIP well and was very happy that Stefanos wrote the DIP and even the druft.

Yes, if something is perceived as bug it becomes a burden to remember that it is isn't. Not sure why anyone resist this improvement. Hm, he seems to be a compiler consultant now, but no longer interested in D?

Maybe the DIP should have pushed harder on what other languages support (might be viewed as a stronger political argument).

>> I see how builtin tuples could be useful for a linalg library. I like how Python allows just using ",". Makes code easier on the eyes
>>
>> x,y = y,x
>
> It is also very desired for lazy zipped tensors.

I don't use tensors much, how does it help zipping?

I sometimes wonder if linalg primitives should be builtin too. Seems like that could allow for better compiler optimization.

On Wednesday, 23 December 2020 at 17:22:28 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 23 December 2020 at 17:08:26 UTC, 9il wrote:
>> https://issues.dlang.org/show_bug.cgi?id=16486
>> https://issues.dlang.org/show_bug.cgi?id=16465
>> https://issues.dlang.org/show_bug.cgi?id=10884
>> and the oldest one reported in 2008
>> https://issues.dlang.org/show_bug.cgi?id=1807
>>
>> C++ templates can be resolved, at least at the level Mir needs this. So, it is a bug in my opinion. But it was said the DIP is required. I can't write DIP well and was very happy that Stefanos wrote the DIP and even the druft.
>
> Yes, if something is perceived as bug it becomes a burden to remember that it is isn't. Not sure why anyone resist this improvement. Hm, he seems to be a compiler consultant now, but no longer interested in D?

Hi is disappeared from the Dlang after that.

> Maybe the DIP should have pushed harder on what other languages support (might be viewed as a stronger political argument).

Have you read the DMD PR  thread (not the DIP itself)?

It was a mockery executed by Atila accompanied by silent Walter's and Andrei's ignoring.

I know Atila in person. However, it doesn't really matter if Atila really didn't understand the DIP reasons or it was a real mockery. The fact that this behavior including real or seeming mockery and real ignoring is a red flag for any professional cooperation.

Atila had been already declared as "new Andrei".

Which was noted right in the DIP to define Atila's privileges to make decisions.
https://github.com/dlang/dmd/pull/9778#issuecomment-498700369

>>> I see how builtin tuples could be useful for a linalg library. I like how Python allows just using ",". Makes code easier on the eyes
>>>
>>> x,y = y,x
>>
>> It is also very desired for lazy zipped tensors.
>
> I don't use tensors much, how does it help zipping?
>
> I sometimes wonder if linalg primitives should be builtin too. Seems like that could allow for better compiler optimization.

On Wednesday, 23 December 2020 at 17:22:28 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 23 December 2020 at 17:08:26 UTC, 9il wrote:

> I don't use tensors much, how does it help zipping?

Safe optimizations. Mir uses unsafe ugly workarounds somehow in some places and doesn't improve some stuff that can be improved. Lazy tensors are used in

https://github.com/typohnebild/numpy-vs-mir

which has few kernels. The fastest one is `ndslice`, which uses lazy zipped tensors. Comparing with Phobos zipped ranges, Mir's zipped tensors are mutable.

On Wednesday, 23 December 2020 at 18:05:40 UTC, 9il wrote:
> Have you read the DMD PR  thread (not the DIP itself)?
>
> It was a mockery executed by Atila accompanied by silent Walter's and Andrei's ignoring.

I am not sure if I read the same one, I didn't perceive it as mockery. Atila seemed to imply that a bigger language change is needed and that this DIP would only fix one bit of what has to change? Then he tried to suggest alternatives. Maybe he did not understand that it makes the compiler look buggy. The communication was not very clear though… Looked more like people talking past each other than mockery.

On Wednesday, 23 December 2020 at 18:23:25 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 23 December 2020 at 18:05:40 UTC, 9il wrote:
>> Have you read the DMD PR  thread (not the DIP itself)?
>>
>> It was a mockery executed by Atila accompanied by silent Walter's and Andrei's ignoring.
>
> I am not sure if I read the same one, I didn't perceive it as mockery. Atila seemed to imply that a bigger language change is needed and that this DIP would only fix one bit of what has to change? Then he tried to suggest alternatives. Maybe he did not understand that it makes the compiler look buggy. The communication was not very clear though… Looked more like people talking past each other than mockery.

Or that was just a very good mockery. But as was said that doesn't really matter for the result we have.

I am using D last 11-12 years. This case wasn't an exception, it was a Dlang failure among consequent others.

On Wednesday, 23 December 2020 at 17:22:28 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 23 December 2020 at 17:08:26 UTC, 9il wrote:
>>
>> C++ templates can be resolved, at least at the level Mir needs this. So, it is a bug in my opinion. But it was said the DIP is required. I can't write DIP well and was very happy that Stefanos wrote the DIP and even the druft.
>
> Yes, if something is perceived as bug it becomes a burden to remember that it is isn't. Not sure why anyone resist this improvement. Hm, he seems to be a compiler consultant now, but no longer interested in D?
>
> Maybe the DIP should have pushed harder on what other languages support (might be viewed as a stronger political argument).
>
That would take someone

1) who really really cares and has lot's of time on their hands
2) is paid to do that job so they're motivated to keep pushing politically (Without clear communication)
3) really needs to get that fixed for the job

None of which seems to me we're making it easy for people without time of their hands to make contribution. Spending hours-days writing a DIP or pull request that doesn't get the attention it deserves can be very demoralizing (undervalued). Even anything as simple as an idea, especially (or at least) coming from a very technical person, deserves some attention and clear feedback/communication. I've seen people quit their job after such experiences...and that's a PAID job.

Looks to me like running away from responsibility or like I've been saying, a missing hand needed to bridge that gap.

On Wednesday, 23 December 2020 at 18:38:01 UTC, 9il wrote:
> Or that was just a very good mockery. But as was said that doesn't really matter for the result we have.

True. Other languages try to iron out perceived flaws. I am quite impressed by how C++ has managed to move, even though it is stuck with its flaws because of the huge installed base (many users). D does not a large installed base so it can move and remove those "perceived bugs". C++ is stuck with the "perceived bugs" and that is what people dislike the most about C++. Any language that wants to take on C++ has to streamline and make the language easy to master. That and a lack of a clear vision on memory management/memory model is D's biggest challenges. Those two aspects are float or sink dimensions, IMHO.

On Wednesday, 23 December 2020 at 19:49:44 UTC, aberba wrote:
> None of which seems to me we're making it easy for people without time of their hands to make contribution. Spending hours-days writing a DIP or pull request that doesn't get the attention it deserves can be very demoralizing (undervalued).

Indeed, if it is ignored and does not lead to a new and improved version, that is demoralizing. But, the value of a DIP isn't that it is implemented, but that it takes part in an iterative process that leads to a better outcome. So, the people who manage a project has to make this visible to those that participate, that they take part in an iterative process that is moving forward.

Project management and team motivation are quite challenging topics, but if one ignore those then there will be less progress, stagnation, or regressions.

> Looks to me like running away from responsibility or like I've been saying, a missing hand needed to bridge that gap.

There has to be a clearly mediated feeling of a spiral of progress, and that has to be communicated by those who take on project management responsibilities.

So, even if the solution provided by a DIP doesn't lead to something there should at least be a feeling that the ISSUE raised is being acknowledged and noted. Which is what I feel was missing in the example given.

On Wednesday, 23 December 2020 at 18:05:40 UTC, 9il wrote:
> On Wednesday, 23 December 2020 at 17:22:28 UTC, Ola Fosheim Grøstad wrote:
>> On Wednesday, 23 December 2020 at 17:08:26 UTC, 9il wrote:
>>> [...]
>>
>> Yes, if something is perceived as bug it becomes a burden to remember that it is isn't. Not sure why anyone resist this improvement. Hm, he seems to be a compiler consultant now, but no longer interested in D?
>
> Hi is disappeared from the Dlang after that.
>
>> Maybe the DIP should have pushed harder on what other languages support (might be viewed as a stronger political argument).
>
> Have you read the DMD PR  thread (not the DIP itself)?
>
> It was a mockery executed by Atila accompanied by silent Walter's and Andrei's ignoring.
>
> I know Atila in person. However, it doesn't really matter if Atila really didn't understand the DIP reasons or it was a real mockery. The fact that this behavior including real or seeming mockery and real ignoring is a red flag for any professional cooperation.
>
> Atila had been already declared as "new Andrei".
>
> Which was noted right in the DIP to define Atila's privileges to make decisions.
> https://github.com/dlang/dmd/pull/9778#issuecomment-498700369
>
>>> [...]
>>
>> I don't use tensors much, how does it help zipping?
>>
>> I sometimes wonder if linalg primitives should be builtin too. Seems like that could allow for better compiler optimization.

Franky speaking, I don't see any mockery, but I'm not a native English speaker,  so I could have missed it.

Said that, if you really see value in the DIP, can I suggest to keep explaining your reason? I'm totally sure everybody here is engaged in discussion with the goal to understand. ...

my 2c

On Wednesday, 23 December 2020 at 16:25:58 UTC, 9il wrote:
> [snip]
> 1.
> Alias template function parameter resolution
> https://github.com/dlang/dmd/pull/9778
>
> [snip]

I gave some thought to potential alternatives, but this is really the simplest way to think about it.

For instance, I would imagine that something like below would be expected to compile if this is ever resolved.

struct Foo(T) {}
alias Bar(T) = Foo!T;
void f(T)(Foo!T x) {}
void b(T)(Bar!T x) {}
void main() {
    auto foo = Foo!int();
    auto bar = Bar!int();
    foo.f;
    foo.b;
    bar.f;
    bar.b;
}

If you instead use template constraints, then you have to rely on helper functions for anything more complicated and you are no longer following DRY. For instance, a function like
enum bool isBar(T) = is(T == Foo!U, U);
void fb(T)(T x) if(isBar!T) {}
will compile (adjusting the calls above), but you are repeating Foo!U.
Because of the bugs mentioned in other posts, replacing isBar with below will not.
enum bool isBar(T) = is(T == Bar!U, U);

Given the similarities between template constraints and concepts, something like below could accomplish something similar
concept Bar(T) = is(T == Foo!U, U);
but that doesn't help you if you want to also be able to use the template alias, as in
auto bar = Bar!int();
This is because Bar(T) in the concept should be passing a Foo!T. You would still need to have the alias for Bar if you want that functionality (and how to name them when they are doing similar things). Abusing C++'s syntax you might have something like
concept Bar(T) = requires(U)() {
    Foo!U; //akin to something like typename T::Foo<U>;
}
where we would basically be telling the compiler that T has to be a Foo!U, which would mean you would have to use Bar like Bar!U...at least that's the idea. I don't think anything like this would work currently in C++.

It's useful to contrast this with implicit conversion. For instance, if instead Bar is something like
struct Baz(T)
{
    Foo!T payload
    alias payload this;
}
but then you can no longer have foo get passed to the b function (suitably adjusted). So implicit conversion isn't the solution. However, it is interesting. The problem is that Baz is a separate type. Even if it's implicitly convertible to Foo, a Foo isn't convertible to it (every Baz is a Foo but no Foos are Baz's). By contrast, the template alias Bar is still a Foo (every Bar is a Foo and some but not all Foos are Bars). So it can be thought of as a constrained version of Foo, though in this case there are no constraints listed. That's where the similarity with C++ concepts come in.