On Wednesday, 28 October 2020 at 06:06:41 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 27 October 2020 at 10:54:46 UTC, Mike Parker wrote:
>> This is the feedback thread for the first round of Community Review of DIP 1037, "Add Unary Operator ...".
>
> Avoid qualitative assumptions of whether this is a success in c++ or not. This is actually a maginal c++ feature that does not fit well with the language.
>
> Please discuss this feature vs more powerful and generic features like comprehensions.

Discuss the feature/operator in the context of all sequence types the language and standard library offers. There is no need for D to end up with more special cases.

(Ease of implementation should not be a distinguishing factor, that leads to fragmentation in the language design.)

On Wed, Oct 28, 2020 at 4:25 PM Ola Fosheim Grøstad via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Wednesday, 28 October 2020 at 06:06:41 UTC, Ola Fosheim Grøstad wrote:
> > On Tuesday, 27 October 2020 at 10:54:46 UTC, Mike Parker wrote:
> >> This is the feedback thread for the first round of Community Review of DIP 1037, "Add Unary Operator ...".
> >
> > Avoid qualitative assumptions of whether this is a success in c++ or not. This is actually a maginal c++ feature that does not fit well with the language.
> >
> > Please discuss this feature vs more powerful and generic features like comprehensions.
>
> Discuss the feature/operator in the context of all sequence types the language and standard library offers. There is no need for D to end up with more special cases.
>
> (Ease of implementation should not be a distinguishing factor, that leads to fragmentation in the language design.)
>

What does this mean? What other sequence types do you expect this to apply to? What special cases are you talking about?

On Wednesday, 28 October 2020 at 08:48:39 UTC, Manu wrote:
> What does this mean? What other sequence types do you expect this to apply to? What special cases are you talking about?

C++ is special casing it to overcome a severe language deficiency.

A tuple can either be seen as a struct or as a sequence. Whatever operations are added for tuples should have counterparts in everything that pertains to structs or sequences in the language.

On Wed, Oct 28, 2020 at 8:15 PM Ola Fosheim Grøstad via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Wednesday, 28 October 2020 at 08:48:39 UTC, Manu wrote:
> > What does this mean? What other sequence types do you expect this to apply to? What special cases are you talking about?
>
> C++ is special casing it to overcome a severe language deficiency.
>
> A tuple can either be seen as a struct or as a sequence. Whatever operations are added for tuples should have counterparts in everything that pertains to structs or sequences in the language.
>

This doesn't help me.

On Wednesday, 28 October 2020 at 10:48:01 UTC, Manu wrote:
> This doesn't help me.

Well, the DIP should argue the case in relation to all other sequence types that are available in the language/standard library. If it does not apply, then make an argument for that for those specific sequence types. The downside then would be that one could argue that the operations are not well designed.

D should try to avoid becoming C++, thus there has to be a strong focus on making the language more unified.

The culprit is this: the more C++like D becomes (feature wise, core semantics could be like C++), the less reason there is for D to exist.

On Wednesday, 28 October 2020 at 10:59:26 UTC, Ola Fosheim Grøstad wrote:
> D should try to avoid becoming C++, thus there has to be a strong focus on making the language more unified.

Maybe UNIFORM is a better term. C++ lacks uniformity. D isn't perfect in this regard either, but D has to improve in that area in order to be more attractive. All features that pulls away from uniformity makes the language harder to learn.

On 10/28/20 12:20 AM, Manu wrote:
> These are all good points. Are you opposed to this DIP? If not, would you consider collaborating on this?
> I don't really know appropriate language to address some of your points. I'm convinced the DIP will fail on account of the points you make, and if I can't correct them, then it's an automatic fail, and I might as well withdraw it now to save myself the torture, and you the time destroying it in a few weeks.
> 
> Or anyone else...? This definitely needs fixing, and I don't really know how to do it.

I agree it's important to address issues raised during review. You could actually edit and insert some of your responses in the DIP itself. Don't forget, the frame of mind is to translate from "DIP plus explanatory forum discussion" to "everything goes in the DIP". When in doubt, state in the DIP.

As this is the feedback thread, I've only focused on things that could improve the DIP, to the best of my ability independently on my take on it. I may add a post in the discussion thread.

Thanks for your work!

On 10/27/20 10:34 PM, Manu wrote:
> I mention that it's a postfix unary operator. I think that implies the precedence, no?
> All the postfix operators work from the inside outwards. If there's precedence levels in there that I didn't notice, then I can amend to make it explicit.

I'd say there's enough subtlety to this to warrant explanation. For starters, it's not quite an operator because operators yield expressions, whereas this yields a comma-separated list.

On Friday, 30 October 2020 at 18:27:22 UTC, Andrei Alexandrescu wrote:
> On 10/27/20 10:34 PM, Manu wrote:
>> I mention that it's a postfix unary operator. I think that implies the precedence, no?
>> All the postfix operators work from the inside outwards. If there's precedence levels in there that I didn't notice, then I can amend to make it explicit.
>
> I'd say there's enough subtlety to this to warrant explanation. For starters, it's not quite an operator because operators yield expressions, whereas this yields a comma-separated list.


The ... operator does yield a tuple expression.
Tuple in. Tuple out.

On Sat, Oct 31, 2020 at 4:30 AM Andrei Alexandrescu via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On 10/27/20 10:34 PM, Manu wrote:
> > I mention that it's a postfix unary operator. I think that implies the
> > precedence, no?
> > All the postfix operators work from the inside outwards. If there's
> > precedence levels in there that I didn't notice, then I can amend to
> > make it explicit.
>
> I'd say there's enough subtlety to this to warrant explanation. For starters, it's not quite an operator because operators yield expressions, whereas this yields a comma-separated list.


Just to be clear, is there a difference between a comma-separated list and
a tuple?
If there is a difference, then `...` results in a tuple, and NOT a comma
separated list. The result of `...` is a normal tuple, like any other
tuple, and it is subject to D's normal expansion rules. This DIP proposes
no effect on existing tuple expansion rules, and plugs into them naturally.