On 03.06.19 20:34, Exil wrote:
> On Monday, 3 June 2019 at 17:43:36 UTC, Timon Gehr wrote:
>> On 20.09.18 19:08, Guillaume Boucher wrote:
>>> On Saturday, 13 January 2018 at 18:28:55 UTC, Timon Gehr wrote:
>>>> However, this proposal is independent of all the other ones, so in the end it is up to Walter and Andrei.
>>>
>>> Have there been any discussions regarding the semantics of _?
>>>
>>> struct G { ~this() { writeln("destruct"); } }
>>> void main() {
>>>      auto _ = G();
>>>      writeln("here");
>>> }
>>>
>>> The DIP currently says this should print first "here" and then "destruct".
>>>
>>> However, as you cannot access the variable later, you most often want to discard the data right away, i.e. print first "destruct" and then "here".
>>>
>>> I personally find the second interpretation more useful.
>>>
>>
>> This has not been discussed, but I agree it should be addressed somehow. The main issue is that right now "_" is a valid identifier.
> 
> Not sure what the use case is for this,
auto (x,_,y) = f();

foreach(_;0..n) { ... }

...

> but if you don't need the value of the variable, assuming from a function or otherwise. You can just not assign it to anything.
> ...

Nope.

> struct G { ~this() { writeln("destruct"); } }
> void main() {
>      G();  // prints "destruct" before "here"
>      writeln("here");
> }
> 
> definitely don't like the idea of changing how scope works. I'd rather not the compiler choose to decide whether it does something one way or another like that.
> 

You mean like when you don't assign the result to anything?

On 03.06.19 18:33, ixid wrote:
> On Wednesday, 19 September 2018 at 21:48:40 UTC, Timon Gehr wrote:
>> So do I, but I need to get a quiet weekend or so to finish this.
>>
>>> I am very tempted to start my own dip on this and finish it.
>>
>> Here's the current state of my implementation in DMD:
>> https://github.com/dlang/dmd/compare/master...tgehr:tuple-syntax
>>
>> It has no tests yet, but basically, with those changes, you can write tuple literals `(1, 2.0, "3")`, you can unpack tuples using `auto (a, b) = t;` or `(int a, string b) = t;`, and tuples can be expanded using alias this on function calls, so you can now write things like `zip([1,2,3],[4,5,6]).map!((a,b)=>a+b)`.
>>
>> The implementation is still missing built-in syntax for tuple types, tuple assignments, and tuple unpacking within function argument lists and foreach loops.
> 
> Hey Timon, any progress on this? I've been excitedly wanting this tuple syntax since your DIP.

I'm afraid no. I'll try to get back to this; I have been busy with work and I have sunk some (ultimately unproductive) time into `__mutable` per Andrei's request.

On 2019-06-03 19:43, Timon Gehr wrote:

> This has not been discussed, but I agree it should be addressed somehow. The main issue is that right now "_" is a valid identifier.

Can a '*' be used instead?

-- 
/Jacob Carlborg

On Tuesday, 4 June 2019 at 18:02:30 UTC, Jacob Carlborg wrote:
> On 2019-06-03 19:43, Timon Gehr wrote:
>
>> This has not been discussed, but I agree it should be addressed somehow. The main issue is that right now "_" is a valid identifier.
>
> Can a '*' be used instead?

Not in all cases:

auto *= G(); // would be very strange if this is allowed

But it can in tuples, which is the second most relevant use case.

The most relevant use case is this one:

foreach(*;0..n) { ... }

So either there's a special case for that or we just continue using _ in those loops (the scoping doesn't matter there).  So '*' can work, but is a bit hacky.

On Friday, 12 January 2018 at 22:44:48 UTC, Timon Gehr wrote:
> As promised [1], I have started setting up a DIP to improve tuple ergonomics in D:
>
> https://github.com/tgehr/DIPs/blob/tuple-syntax/DIPs/DIP1xxx-tg.md
>
>
> This DIP aims to make code like the following valid D:
>
> ---
> auto (a, b) = (1, 2);
> (int a, int b) = (1, 2);
> ---
>
> ---
> foreach((sum, diff); [(1, 2), (4, 3)].map!((a, b) => (a + b, a - b)))
> {
>     writeln(sum, " ", diff);
> }
> /+ prints:
> 3 -1
> 7 1
> +/
> ---
>
> Before going ahead with it, I'd like some preliminary community input:
>
> - I'm not yet completely satisfied with the DIP.
>   (See section "Limitations".)
>   Please let me know suggestions or further concerns you might have.
>
>
> - There are good example use cases missing. While I'm confident I could
>   invent a few of them given a little time, I thought maybe I can
>   expedite the process and make the point more convincingly by asking
>   for use cases you encountered in your own code. The DIP already
>   contains an example due to bearophile.
>
>
> [1] https://forum.dlang.org/post/or625h$2hns$1@digitalmars.com

Any chance you can work further on this DIP?

I currently port a python library to D and would like to keep the coding
as similar to Python as possible (Decreases maintenance effort in future
for including changes made in the original coding).

The features proposed in your DIP actually are a big win here.

Kind regards
André

Is this DIP dead?
Several parts of the proposal seem very nice to me, and it seems like a waste not to have it considered. (assuming https://github.com/tgehr/DIPs/blob/tuple-syntax/DIPs/DIP1xxx-tg.md is the latest version of this not submitted proposal)

Slightly unrelated, but wouldn't it be better to change the comma operator to a different symbol entirely? I can see why it has some merit, if not for the poor symbol choice.
(interestingly there's already a DIP that may be related to making new symbols possible https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1007.md, though i may be mistaken in interpreting it as such)

On Friday, 1 January 2021 at 18:53:39 UTC, Rekel wrote:
> Is this DIP dead?
> Several parts of the proposal seem very nice to me, and it seems like a waste not to have it considered. (assuming https://github.com/tgehr/DIPs/blob/tuple-syntax/DIPs/DIP1xxx-tg.md is the latest version of this not submitted proposal)
>
> Slightly unrelated, but wouldn't it be better to change the comma operator to a different symbol entirely?
And what would you like it to be?

 I can see why it
> has some merit, if not for the poor symbol choice.
All my experience with such a feature used comma for ignored values.

> (interestingly there's already a DIP that may be related to making new symbols possible https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1007.md, though i may be mistaken in interpreting it as such)

On Saturday, 2 January 2021 at 14:47:17 UTC, aberba wrote:
> And what would you like it to be?
I mean if it's truly impeding on desired functionality, I wouldn't mind any possible alternative. Something like '\' seems simple enough to me.

On 01.01.21 19:53, Rekel wrote:
> Is this DIP dead?

Let's say it's hibernating. Originally I wanted to spend time on it during the hackathon at dconf 2018. Andrei wanted me to instead work on __mutable, claiming it was of strategic importance while tuples are not. He then completely binned __mutable later. Right now I am just too busy to champion this, and the lack of enthusiasm from decision makers does not help motivate me to attempt trading some of my health for tuples.

> Several parts of the proposal seem very nice to me, and it seems like a waste not to have it considered. (assuming https://github.com/tgehr/DIPs/blob/tuple-syntax/DIPs/DIP1xxx-tg.md is the latest version of this not submitted proposal)
> ...

It's mostly a matter of rebasing/finishing the implementation and possibly arguing on the forums for a couple of weeks/months.

> Slightly unrelated, but wouldn't it be better to change the comma operator to a different symbol entirely?

Ideally we'd just add tuple syntax and then use (..,..,..)[$-1] as a replacement for the comma operator.

On Sunday, 3 January 2021 at 05:44:57 UTC, Timon Gehr wrote:
> On 01.01.21 19:53, Rekel wrote:
>> Slightly unrelated, but wouldn't it be better to change the comma operator to a different symbol entirely?
>
> Ideally we'd just add tuple syntax and then use (..,..,..)[$-1] as a replacement for the comma operator.

Since using the value of a comma expression is currently forbidden, it should be fine to replace comma expressions with tuple expressions as long as the order of evaluation remains the same.