This is the discussion thread for the first round of Community Review of DIP 1037, "Add Unary Operator ...":

https://github.com/dlang/DIPs/blob/ba81eec84ddf0aeeb2cb652743b292455ec8c62a/DIPs/DIP1037.md

The review period will end at 11:59 PM ET on November 10, or when I make a post declaring it complete. Discussion in this thread may continue beyond that point.

Here in the discussion thread, you are free to discuss anything and everything related to the DIP. Express your support or opposition, debate alternatives, argue the merits, etc.

However, if you have any specific feedback on how to improve the proposal itself, then please post it in the feedback thread. The feedback thread will be the source for the review summary that I will write at the end of this review round. I will post a link to that thread immediately following this post. Just be sure to read and understand the Reviewer Guidelines before posting there:

https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md

And my blog post on the difference between the Discussion and Feedback threads:

https://dlang.org/blog/2020/01/26/dip-reviews-discussion-vs-feedback/

Please stay on topic here. I will delete posts that are completely off-topic.

On Tuesday, 27 October 2020 at 10:54:07 UTC, Mike Parker wrote:
>
> However, if you have any specific feedback on how to improve the proposal itself, then please post it in the feedback thread. The feedback thread will be the source for the review summary that I will write at the end of this review round. I will post a link to that thread immediately following this post.

The feedback thread is here:

https://forum.dlang.org/post/rihufokcywwlityflfco@forum.dlang.org

On Tuesday, 27 October 2020 at 10:54:07 UTC, Mike Parker wrote:
> This is the discussion thread for the first round of Community Review of DIP 1037, "Add Unary Operator ...":
>
> https://github.com/dlang/DIPs/blob/ba81eec84ddf0aeeb2cb652743b292455ec8c62a/DIPs/DIP1037.md

Is there a risk of causing some form of ambiguity with variadic functions? For example:

void a(int[] a ...);
void b(int[]...);
void c(int...);

alias A = AliasSeq!(int);
void d(A...);

I didn't know `c` was legal, but apparently it is (and therefor `d` as well).

--
/Jacob Carlborg

On Wed, Oct 28, 2020 at 9:05 PM Jacob Carlborg via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Tuesday, 27 October 2020 at 10:54:07 UTC, Mike Parker wrote:
> > This is the discussion thread for the first round of Community Review of DIP 1037, "Add Unary Operator ...":
> >
> >
> https://github.com/dlang/DIPs/blob/ba81eec84ddf0aeeb2cb652743b292455ec8c62a/DIPs/DIP1037.md
>
> Is there a risk of causing some form of ambiguity with variadic functions? For example:
>
> void a(int[] a ...);
> void b(int[]...);
> void c(int...);
>
> alias A = AliasSeq!(int);
> void d(A...);
>
> I didn't know `c` was legal, but apparently it is (and therefor
> `d` as well).
>

What does `c` mean?
Is it possible that c and d are identical things here, even with my DIP in
place?

Your example `void c(int...)` mangles as `void c(int)`, and it's also
callable only with a single int arg.
Under my DIP, `d` as you show will perform an identity map, which yields
`void d(int)`, so the result is identical.
I explored for ambiguities to the extent of my imagination but I didn't
find any. The is() expression was where I was most concerned about
ambiguities.

On Wed, Oct 28, 2020 at 9:44 PM Manu <turkeyman@gmail.com> wrote:

> On Wed, Oct 28, 2020 at 9:05 PM Jacob Carlborg via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
>
>> On Tuesday, 27 October 2020 at 10:54:07 UTC, Mike Parker wrote:
>> > This is the discussion thread for the first round of Community Review of DIP 1037, "Add Unary Operator ...":
>> >
>> >
>> https://github.com/dlang/DIPs/blob/ba81eec84ddf0aeeb2cb652743b292455ec8c62a/DIPs/DIP1037.md
>>
>> Is there a risk of causing some form of ambiguity with variadic functions? For example:
>>
>> void a(int[] a ...);
>> void b(int[]...);
>> void c(int...);
>>
>> alias A = AliasSeq!(int);
>> void d(A...);
>>
>> I didn't know `c` was legal, but apparently it is (and therefor
>> `d` as well).
>>
>
> What does `c` mean?
> Is it possible that c and d are identical things here, even with my DIP in
> place?
>

On Tuesday, 27 October 2020 at 10:54:07 UTC, Mike Parker wrote:
> This is the discussion thread for the first round of Community Review of DIP 1037, "Add Unary Operator ...":

I think it should be made more generic and flexible. Make it work with all sequence types that provides a length and indexing. Make it possible to offset. Make it work for empty sequences (initial value for fold/reduce). Make the comma-expansion more intuitive. E.g. (pseduo):

Given:

seq1 = /* 1 ,2, 3 */
seq2 = /* 10, 20, 30, 40, 50*/


IN:
(seq1[_]*10 + seq2[_+1], ...)

OUT (e.g. length = min(seq1.length, seq2.length):
(seq1[0]*10 + seq2[1], seq1[1]*10 + seq2[2], seq1[2]*10 + seq2[3])

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

> On Tuesday, 27 October 2020 at 10:54:07 UTC, Mike Parker wrote:
> > This is the discussion thread for the first round of Community Review of DIP 1037, "Add Unary Operator ...":
>
> I think it should be made more generic and flexible. Make it work with all sequence types that provides a length and indexing.


Definitely not my DIP. I can immediately imagine heaps of issues with that
idea, and I have never wanted that before.
If you want to do a non-static map, then use `map`, which accepts a lambda
and looks and feels very natural and convenient.

Make it possible to offset.


Not sure what this means? You can slice tuples in D, does that not give you the ability to offset as you like?

Make it work for empty sequences (initial
> value for fold/reduce).


I don't think this is necessary, and it is deliberately omitted. You can
append a limit value to a tuple trivially using something like
AliasSeq!(limit, MyTup).
Perhaps in the future if we ever get first-class tuples, you can use `~` to
intuitively concatenate tuples, and I think that's more proper than what
C++ does. If it turns out I'm wrong and it should exist, then it's a
trivial expansion.

Make the comma-expansion more intuitive.
> E.g. (pseduo):
>
> Given:
>
> seq1 = /* 1 ,2, 3 */
> seq2 = /* 10, 20, 30, 40, 50*/
>
>
> IN:
> (seq1[_]*10 + seq2[_+1], ...)
>
> OUT (e.g. length = min(seq1.length, seq2.length):
> (seq1[0]*10 + seq2[1], seq1[1]*10 + seq2[2], seq1[2]*10 + seq2[3])


That looks like a minefield of grammatical issues. Why would you prefer that with the comma separating the expression and `...`?

On Wednesday, 28 October 2020 at 14:48:48 UTC, Manu wrote:
> Definitely not my DIP. I can immediately imagine heaps of issues with that
> idea, and I have never wanted that before.
> If you want to do a non-static map, then use `map`, which accepts a lambda
> and looks and feels very natural and convenient.

Make the syntax uniform. Don't continue with special cases...

> Not sure what this means? You can slice tuples in D, does that not give you the ability to offset as you like?

That was an example. Reverse. Every other etc.

> I don't think this is necessary, and it is deliberately omitted.

That is a serious omission. Fold needs an initial value in order to be generic.

>> IN:
>> (seq1[_]*10 + seq2[_+1], ...)
>>
>> OUT (e.g. length = min(seq1.length, seq2.length):
>> (seq1[0]*10 + seq2[1], seq1[1]*10 + seq2[2], seq1[2]*10 + seq2[3])
>
>
> That looks like a minefield of grammatical issues.

No, it isn't. D uses a recursive descent parser and it will evaluate the first expression to an expression with a special token. Trivial extension of the parser.

> Why would you prefer that with the comma separating the expression and `...`?

Because what you proposed is not intuitive:

"(seq1)..."

does not give any hint of it being expanded to a comma separated list. That is not good from a usability point of view (legibility).

On Wednesday, 28 October 2020 at 14:56:10 UTC, Ola Fosheim Grøstad wrote:
>> I don't think this is necessary, and it is deliberately omitted.
>
> That is a serious omission. Fold needs an initial value in order to be generic.

You can add an initial value outside of the fold expression:

    false || Tup == 10 || ...

On Wednesday, 28 October 2020 at 15:05:19 UTC, Paul Backus wrote:
> You can add an initial value outside of the fold expression:
>
>     false || Tup == 10 || ...

Ok, but the problem is in generic code. You could adopt init as the initial value for fold, but it fails miserably for floats as they don't have 0 as the init, but NaN...

Will it work with overloads so that the initial value can be a completely different type? (If you want to trap empty tuples, but have no unused value.)