On 8/10/23 17:47, Basile B. wrote:
> On Thursday, 10 August 2023 at 15:41:16 UTC, ryuukk_ wrote:
>> On Thursday, 10 August 2023 at 10:41:12 UTC, Basile B. wrote:
>>> On Thursday, 10 August 2023 at 02:28:08 UTC, Timon Gehr wrote:
>>>> On 8/8/23 18:47, Vijay Nayar wrote:
>>>>>
>>>>> **Question**: Would D benefit from using commas to define tuples rather than triggering an error when the result of a comma-expression is used? Right now, because the errors, the result of a comma expression is a bit of "unused real estate" in the language.
>>>>>
>>>>> The easy syntax for dealing with tuples of values is especially useful in writing logic for machine-learning algorithms, and has helped Python gain and hold a strong foothold in this area, but where performance is needed, Python libraries like PyTorch turn to C++. Perhaps this could be D instead.
>>>>
>>>> The answer is yes, though I don't think changing the precedence fits the D grammar.
>>>>
>>>> My DIP draft: https://github.com/tgehr/DIPs/blob/master/DIPs/DIP1xxx-tg.md
>>>>
>>>
>>> That link is for static-foreach, right one is https://github.com/tgehr/DIPs/blob/tuple-syntax/DIPs/DIP1xxx-tg.md
>>
>> 6 years ago, wow..
>>
>> Builtin tuple has been on my wishlist for a long time, time flies too fast..
> 
> I'm reading the DIP with fresh eyes today, after having implemented tuples for another language. One think I see now, as that Timon's DIP, does not investigate, is that tuple deconstruction could use [in-situ variable declarations](https://gitlab.com/styx-lang/styx/-/releases/v0.10.15), i.e something that's not especially made for tuples and that works as a normal primary expression.

Well, I think that should be a separate proposal, but it's syntactically compatible. In any case, I would strongly prefer to be able to still do `auto (x,y) = t;` in addition to `(auto x, auto y) = t;`

On 8/10/23 23:38, Basile B. wrote:
> On Thursday, 10 August 2023 at 19:39:46 UTC, Timon Gehr wrote:
>> On 8/10/23 17:47, Basile B. wrote:
>>> ...
>>> I'm reading the DIP with fresh eyes today, after having implemented tuples for another language. One think I see now, as that Timon's DIP, does not investigate, is that tuple deconstruction could use [in-situ variable declarations](https://gitlab.com/styx-lang/styx/-/releases/v0.10.15), i.e something that's not especially made for tuples and that works as a normal primary expression.
>>
>> Well, I think that should be a separate proposal, but it's syntactically compatible. In any case, I would strongly prefer to be able to still do `auto (x,y) = t;` in addition to `(auto x, auto y) = t;`
> 
> whe have var decl syntax for `if`, since recently for `while` too... It's pretty clear that "in situ" variable decls are required...unless D continues on making special cases.

To be clear, I am in favor, it's just that a tuple DIP is probably the wrong vessel for it.

On Thursday, 10 August 2023 at 19:39:46 UTC, Timon Gehr wrote:
> On 8/10/23 17:47, Basile B. wrote:
>> On Thursday, 10 August 2023 at 15:41:16 UTC, ryuukk_ wrote:
>>> [...]
>> 
>> I'm reading the DIP with fresh eyes today, after having implemented tuples for another language. One think I see now, as that Timon's DIP, does not investigate, is that tuple deconstruction could use [in-situ variable declarations](https://gitlab.com/styx-lang/styx/-/releases/v0.10.15), i.e something that's not especially made for tuples and that works as a normal primary expression.
>
> Well, I think that should be a separate proposal, but it's syntactically compatible. In any case, I would strongly prefer to be able to still do `auto (x,y) = t;` in addition to `(auto x, auto y) = t;`

`auto (x,y) = t;` works but `(auto x, auto y) = t;` does not because of the double inference.