On Thursday, 24 December 2020 at 15:00:16 UTC, jmh530 wrote:
> That Foo-ish reminds me of something in D like
>
>     static if (__traits(compiles, {
>         auto temp = Foo!T.init;
>     }))

Yes, it is similar in spirit. It is pretty much the same as the C++17 version, but easier to write, especially when you require many operators (e.g. "a+b", "a*b" etc). I am not sure if C++20 concepts bring anything truly new, but easier on the eyes and more likely to be used correctly. Which is important. A new feature isn't necessarily about making new things possible, encouraging correct code is just as important.

On Thursday, 24 December 2020 at 14:14:33 UTC, 9il wrote:
> On Thursday, 24 December 2020 at 14:08:32 UTC, welkam wrote:
>> On Wednesday, 23 December 2020 at 18:05:40 UTC, 9il wrote:
>>> It was a mockery executed by Atila
>> Read the all comments and didnt saw any mockery
>
> Yes, it wasn't explicit. He didn't write bad words, he did a bad decision. Bad for D.

Big difference between bad decision and mockery. It's very possible he was wrong, but I don't think he wasn't taking it seriously.

On Thursday, 24 December 2020 at 14:14:33 UTC, 9il wrote:
> On Thursday, 24 December 2020 at 14:08:32 UTC, welkam wrote:
>> On Wednesday, 23 December 2020 at 18:05:40 UTC, 9il wrote:
>>> It was a mockery executed by Atila
>> Read the all comments and didnt saw any mockery
>
> Yes, it wasn't explicit. He didn't write bad words, he did a bad decision. Bad for D.

I apologise if what I wrote came across as mockery; it certainly wasn't intended that way.

How would you have liked for me to have handled it better?

On Tuesday, 29 December 2020 at 16:14:59 UTC, Atila Neves wrote:
> On Thursday, 24 December 2020 at 14:14:33 UTC, 9il wrote:
>> On Thursday, 24 December 2020 at 14:08:32 UTC, welkam wrote:
>>> On Wednesday, 23 December 2020 at 18:05:40 UTC, 9il wrote:
>>>> It was a mockery executed by Atila
>>> Read the all comments and didnt saw any mockery
>>
>> Yes, it wasn't explicit. He didn't write bad words, he did a bad decision. Bad for D.
>
> I apologise if what I wrote came across as mockery; it certainly wasn't intended that way.
>
> How would you have liked for me to have handled it better?

From my day to day experience as developer, some topics you cannot discuss using mail / forum posts/ github pr.

Face to face communication is best and phone communication is second best.

If a pr is in a stuck situation, you may think of having a phone call if possible.
(Maybe slack/discord supporting this).

In many cases this will help to have a better understanding of of the pov of the other developer.

Kind regards
Andre

On Tuesday, 29 December 2020 at 16:14:59 UTC, Atila Neves wrote:
> On Thursday, 24 December 2020 at 14:14:33 UTC, 9il wrote:
>> On Thursday, 24 December 2020 at 14:08:32 UTC, welkam wrote:
>>> On Wednesday, 23 December 2020 at 18:05:40 UTC, 9il wrote:
>>>> It was a mockery executed by Atila
>>> Read the all comments and didnt saw any mockery
>>
>> Yes, it wasn't explicit. He didn't write bad words, he did a bad decision. Bad for D.
>
> I apologise if what I wrote came across as mockery; it certainly wasn't intended that way.
>
> How would you have liked for me to have handled it better?

I am not speaking for Ilya, but from skimming through the dialogue it struck me that you didn't respond from the perspective of managing the process, but from a pure engineer mindset of providing alternatives.

It would've been better if you started by 1. understanding the issue 2. acknowledging that the type system has an obvious bug 3. looking at the issue from the perspective of the person bringing attention to the issue. I don't think anyone was looking for workarounds, but looking for

1. acknowledgment of the issue
2. acknowledgment of what the issue leads to in terms of inconvenience
3. a forward looking vision for future improvements

On Tuesday, 29 December 2020 at 19:59:56 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 29 December 2020 at 16:14:59 UTC, Atila Neves wrote:
>> On Thursday, 24 December 2020 at 14:14:33 UTC, 9il wrote:
>>> On Thursday, 24 December 2020 at 14:08:32 UTC, welkam wrote:
>>>> On Wednesday, 23 December 2020 at 18:05:40 UTC, 9il wrote:
>>>>> It was a mockery executed by Atila
>>>> Read the all comments and didnt saw any mockery
>>>
>>> Yes, it wasn't explicit. He didn't write bad words, he did a bad decision. Bad for D.
>>
>> I apologise if what I wrote came across as mockery; it certainly wasn't intended that way.
>>
>> How would you have liked for me to have handled it better?
>
> I am not speaking for Ilya, but from skimming through the dialogue it struck me that you didn't respond from the perspective of managing the process, but from a pure engineer mindset of providing alternatives.
>
> It would've been better if you started by 1. understanding the issue 2. acknowledging that the type system has an obvious bug 3. looking at the issue from the perspective of the person bringing attention to the issue. I don't think anyone was looking for workarounds, but looking for
>
> 1. acknowledgment of the issue
> 2. acknowledgment of what the issue leads to in terms of inconvenience
> 3. a forward looking vision for future improvements

+1

On Sunday, 3 January 2021 at 06:35:23 UTC, 9il wrote:
> On Tuesday, 29 December 2020 at 19:59:56 UTC, Ola Fosheim Grøstad wrote:
>> On Tuesday, 29 December 2020 at 16:14:59 UTC, Atila Neves wrote:
>>> On Thursday, 24 December 2020 at 14:14:33 UTC, 9il wrote:
>>>> On Thursday, 24 December 2020 at 14:08:32 UTC, welkam wrote:
>>>>> On Wednesday, 23 December 2020 at 18:05:40 UTC, 9il wrote:
>>>>>> It was a mockery executed by Atila
>>>>> Read the all comments and didnt saw any mockery
>>>>
>>>> Yes, it wasn't explicit. He didn't write bad words, he did a bad decision. Bad for D.
>>>
>>> I apologise if what I wrote came across as mockery; it certainly wasn't intended that way.
>>>
>>> How would you have liked for me to have handled it better?
>>
>> I am not speaking for Ilya, but from skimming through the dialogue it struck me that you didn't respond from the perspective of managing the process, but from a pure engineer mindset of providing alternatives.
>>
>> It would've been better if you started by 1. understanding the issue 2. acknowledging that the type system has an obvious bug 3. looking at the issue from the perspective of the person bringing attention to the issue. I don't think anyone was looking for workarounds, but looking for
>>
>> 1. acknowledgment of the issue
>> 2. acknowledgment of what the issue leads to in terms of inconvenience
>> 3. a forward looking vision for future improvements
>
> +1

I don't want to be the guy that comes and just takes a missive dump in the middle of the room but I feel like I have to.

The whole language change process is not a place to get tribe`s validation or get emotional support for your boo boos. Its like looking for a virgin partner in a brothel. Makes no sense. You should view it more like this
https://images.theconversation.com/files/31778/original/zhrxbdsm-1379916057.jpg?ixlib=rb-1.1.0&q=45&auto=format&w=926&fit=clip

The way I saw it the whole argumentation for a language change went like this:
9il: This would be helpful for my lib
Atila: Im not convinced this is good addition to the language

Thats it. No more good arguments came later. If proposal has only this kind of argument then ofcourse it will be rejected. Even if the idea is good.

You should put yourself in the boots of Atila. If you accept a change that later turns out to be bad idea you cant just take it out. We all would have to be with it for 10 or more years. So to avoid situation that I described a proposal needs to have solid argumentation and cost/benefit ratio needs to be clear to make good decision.

And for the end I want to point out that your proposal is not in the same category as ast macros. If you or some one else comes up with solid arguments then the outcome might be different. As for me. Im do not know ins and outs of templates to make a judgment if your proposal is good or not. No one showed how it would benefit the code I write.

On Sunday, 3 January 2021 at 20:31:41 UTC, welkam wrote:
> You should put yourself in the boots of Atila. If you accept a change that later turns out to be bad idea you cant just take it out.

This is just silly. You don't have to accept a specific solution...

...but...

YOU DO HAVE TO ACKNOWLEDGE A TYPE SYSTEM BUG!

If an indirection through an alias causes type unification to fail then that is a serious type system failure. No excuses please...

"workarounds" are indeed just excuses, telling people "workarounds" they already know about is borderline offensive. I wouldn't call it mocking, but I certainly see why it can be perceived as such.

On Sunday, 3 January 2021 at 20:31:41 UTC, welkam wrote:
> [snip]
>
> The way I saw it the whole argumentation for a language change went like this:
> 9il: This would be helpful for my lib
> Atila: Im not convinced this is good addition to the language
>
> Thats it. No more good arguments came later. If proposal has only this kind of argument then ofcourse it will be rejected. Even if the idea is good.
>
> You should put yourself in the boots of Atila. If you accept a change that later turns out to be bad idea you cant just take it out. We all would have to be with it for 10 or more years. So to avoid situation that I described a proposal needs to have solid argumentation and cost/benefit ratio needs to be clear to make good decision.

What happened was more that Atila said why not use template constraints and Ilya replied it makes things overly complicated and Atila responded about a workaround existing and he didn't see why to add.

Obviously, if Atila or Walter is not in favor of something, it's usually better to know that sooner rather than later. However, it is a bit unfortunate that this never made its way farther through the DIP process. There was a first round review, but I think it was postponed before formal assessment.

>
> And for the end I want to point out that your proposal is not in the same category as ast macros. If you or some one else comes up with solid arguments then the outcome might be different. As for me. Im do not know ins and outs of templates to make a judgment if your proposal is good or not. No one showed how it would benefit the code I write.

If you aren't writing templates, then it wouldn't affect you. However, it was deemed beneficial enough that a form of it was added to C++ as part of C++ 11 (was news to me as I rarely write C++). The paper on it is here [1], though it doesn't really get into the benefits of it. I'm sure there is a lot of C++ 11 and later code out there that uses the C++11 version of the idea.

Nevertheless, there are some differences between the C++11 template aliases and these. C++11 adds the using syntax in addition to the typedef syntax. D already has the alias syntax, which is like using. The difference is that D's template alias syntax works when defining variables. It only doesn't work the same with type deduction in functions. In addition, one reason the DIP was postponed because it really had only addressed the short form template alias, not the long form. However, the C++ version only seems to support the equivalent of the short form.

Regardless, the DIP likely could have been improved by mentioning its inclusion in C++ 11 (and perhaps focused a bit less on implementation).

I wonder if the inability to do this would inhibit the ability of D code to interact with C++ code bases. For instance, what if you have a C++ function that takes a template alias and try to call it in D. Would you have to write out the target of the alias to get it to work? This kind of thing could be important. You wouldn't be able to use the same template aliases in D the way you use them in C++.

If the DIP remained focused on C++ compatibility (if that is an actual issue), then it would only need to support the short form syntax (though that may raise questions as to why not support both).


[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1489.pdf

On Sunday, 3 January 2021 at 22:50:16 UTC, Ola Fosheim Grøstad wrote:
> On Sunday, 3 January 2021 at 20:31:41 UTC, welkam wrote:
>> You should put yourself in the boots of Atila. If you accept a change that later turns out to be bad idea you cant just take it out.
>
> This is just silly. You don't have to accept a specific solution...
>
> ...but...
>
> YOU DO HAVE TO ACKNOWLEDGE A TYPE SYSTEM BUG!
>
> If an indirection through an alias causes type unification to fail then that is a serious type system failure. No excuses please...
>
> "workarounds" are indeed just excuses, telling people "workarounds" they already know about is borderline offensive. I wouldn't call it mocking, but I certainly see why it can be perceived as such.

I suppose the answer would be that D doesn't pretend to support all C++ template features and the bug is not a bug because we live with this somehow for years. I didn't believe it when I got a similar answer about IEEE floating-point numbers: D doesn't pertinent to be IEEE 754 compatible language and the extended precision bug is declared to be a language feature. I suppose we shouldn't expect D to pretend to be a robust language for large business projects.