www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Python-like Use of the Comma Expression

reply Vijay Nayar <madric gmail.com> writes:
**TL;DR**: The comma operator has little use in D, but perhaps it 
could be used like in Python, to define tuple expressions.

**Context**:

In D, one can write a comma expression, similar to C and C++: 
https://dlang.org/spec/expression.html#comma_expression

Comma itself is a low precedence operator, lower than assignment. 
Thus, consider the following two C examples:

```c
#include <stdio.h>

int main() {
   int a;
   a = 1, 2, 3;
   printf("%d\n", a);  // Outputs: 1
   return 0;
}
```

```c
#include <stdio.h>

int main() {
   int a;
   a = (1, 2, 3);
   printf("%d\n", a);  // Outputs: 3
   return 0;
}
```

The usage of the comma operator like this is counter-intuitive, 
and almost always leads to errors. In fact, in D, using the 
result of a comma expression is entirely forbidden.

```d
void main()
{
   int b = (1, 2, 3);
   assert(b == 3);
}

// onlineapp.d(3): Error: using the result of a comma expression 
is not allowed
```

The comma expression is mostly viewed as a shortcut to write 
multiple expressions on a single line, offering only a few 
benefits over just using semi-colons. For example:

```d
int a = 1; int b = 2;
int a = 1, b = 2;  // The type doesn't have to be repeated.
```

**Comparison with Python**:

In Python, tuples are a built-in type, defined using parenthesis. 
  E.g. `(1, 2, 3)` is a tuple with three numbers, while `(3, 
"Bob", 1.2)` is a tuple with a number, string, and float. 
https://docs.python.org/3/tutorial/datastructures.html#tuples-and-sequences

The parenthesis are actually optional in Python, meaning one can 
create a tuple like `1, 2, 3`. Moreover, tuples can be used in 
assignment expressions as well, as illustrated in the following 
example:

```python

a, b, c = 1, 2, 3
```

Additionally, tuples can also be used as the return type of 
functions, e.g.:
```python

and returns

def evalAndDiv(expression, variables):
   ...
   return result, derivative

r,d = evalAndDiv(myExpression, myVariables)
```

A built-in recognition of tuples also dove-tails nicely with 
things like `foreach` loops, which currently have a special 
implementation for iterating over associative-arrays: 
https://dlang.org/spec/hash-map.html#aa_example_iteration

**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.
Aug 08 2023
next sibling parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
We had what was known as comma expression, it was removed in preparation 
for tuples.

So yes, its already on the todo list for us as a community! Although no 
time scale for this at the present I believe.
Aug 08 2023
prev sibling next sibling parent reply sighoya <sighoya gmail.com> writes:
On Tuesday, 8 August 2023 at 16:47:25 UTC, Vijay Nayar wrote:


 ```python

 a, b, c = 1, 2, 3
 ```


Don't like it because if a and b predefined with -1 and 0 I would 
assume to get a tuple:
(-1,0,1,2,3)

This notion also fits to default arguments we already have in D.
Aug 08 2023
parent reply Vijay Nayar <madric gmail.com> writes:
On Tuesday, 8 August 2023 at 19:18:42 UTC, sighoya wrote:

 On Tuesday, 8 August 2023 at 16:47:25 UTC, Vijay Nayar wrote:


 ```python

 a, b, c = 1, 2, 3
 ```


 Don't like it because if a and b predefined with -1 and 0 I 
 would assume to get a tuple:
 (-1,0,1,2,3)

 This notion also fits to default arguments we already have in D.


In Python, there is also a syntax for default arguments that is 
identical to D: 
https://www.geeksforgeeks.org/default-arguments-in-python/

Using the comma operator to define tuples would require changing 
the operator precedence. Rather than being at the lowest 
priority, with assignment being above it, it would be a higher 
priority than assignment.

Thus you would end up with:
```
(a, b, c) = (1, 2, 3)
```

Rather than:
```
(a), (b), (c = 1), 2, 3
```

This change in priority would be specific to top-level 
statements, it would not subvert the parsing of a function's 
argument list.
Aug 08 2023
parent sighoya <sighoya gmail.com> writes:
On Tuesday, 8 August 2023 at 21:00:06 UTC, Vijay Nayar wrote:


 This change in priority would be specific to top-level 
 statements, it would not subvert the parsing of a function's 
 argument list.


Then we have some kind of non uniformity between function 
declarations and top level statements.
And what about this statement?:
```D
int a,b=1,c;
```
Aug 08 2023
prev sibling next sibling parent Quirin Schroll <qs.il.paperinik gmail.com> writes:
On Tuesday, 8 August 2023 at 16:47:25 UTC, Vijay Nayar wrote:

 **TL;DR**: The comma operator has little use in D, but perhaps 
 it could be used like in Python, to define tuple expressions.


You can use something like tuple assignment, you can get pretty 
far simulating that with current D’s tools:
```d
struct t
{
     import std.typecons : tuple;
     static opIndex(Ts...)(Ts args) => tuple(args);

     alias opIndexAssign = opIndexOpAssign!"";
     template opIndexOpAssign(string op)
     {
         static void opIndexOpAssign(R, Ts...)(R rhs, ref Ts lhs)
         {
             static foreach (i; 0 .. Ts.length)
             	mixin("lhs[i] ", op,"= rhs[i];");
         }
     }
}

void main()
{
     int x;
     double y;
     t[x, y] = t[2, 3.14];
     assert(x == 2);
     assert(y == 3.14);
     t[x, y] += t[3, 2.71];
     assert(x == 5);
     assert(y == 3.14 + 2.71);
}
```

It doesn’t work with non-copyable values, but it can be made to 
work with some effort (I’ve done that). Other than that, this 
little thing gets you quite far. A rough outline of how to 
support non-copyable types: Make your own tuple-like type to 
store the values that went into and “store” a compile-time bool 
array of whether the values were rvalues or lvalues. When the 
values are read, return originally-lvalue values by reference and 
move the originally-rvalue values (return by value).

Obviously it can’t do declarations and a few other things that 
language-level tuple support would (in all likelihood) bring.
Aug 09 2023
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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

This will have to be adapted a bit as Walter prefers an alternative 
solution to using `alias this` for expansion in function arguments.

Partial implementation of the DIP (has some known limitations even in 
implemented features):
https://github.com/tgehr/dmd/tree/tuple-syntax

My dconf talk will be partially about this:
https://dconf.org/2023/index.html#timong
Aug 09 2023
parent reply Basile B. <b2.temp gmx.com> writes:
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
Aug 10 2023
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 8/10/23 12:41, 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


Oops! Not sure how I accidentally switched back branches (it was 4:28 am 
though). Thanks for the correction!
Aug 10 2023
prev sibling parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
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..
Aug 10 2023
parent reply Basile B. <b2.temp gmx.com> writes:
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.
Aug 10 2023
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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;`
Aug 10 2023
next sibling parent reply Basile B. <b2.temp gmx.com> writes:
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:

 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;`


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.
Aug 10 2023
next sibling parent Basile B. <b2.temp gmx.com> writes:
On Thursday, 10 August 2023 at 21:38:25 UTC, 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:

 [...]


 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.


See https://dlang.org/spec/statement.html#if-statement.
That's just silly. IfCondition could just be an expression.
Aug 10 2023
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
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.
Aug 10 2023
prev sibling parent reply Nick Treleaven <nick geany.org> writes:
On Thursday, 10 August 2023 at 21:38:25 UTC, Basile B. wrote:

 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.


For `if (auto x = expr)`, the scope of `x` includes the 
*ThenStatement*.
For `if ((auto x = expr) || b)`, `x` can have similar scope.
For `if (b && (auto x = expr))`, `x` can have similar scope.
I think the above two cases could be supported in D.

For `if (b || (auto x = expr))`, `x` may be uninitialized if it 
is accessible in the *ThenStatement*. Does Styx forbid that and 
similar cases?

Also for `if (b || ((auto x = expr) && x.b))`, `x` is safely used 
but it may be uninitialized if its scope extends to the 
*ThenStatement*.
Aug 11 2023
parent Basile B. <b2.temp gmx.com> writes:
On Friday, 11 August 2023 at 12:16:49 UTC, Nick Treleaven wrote:

 On Thursday, 10 August 2023 at 21:38:25 UTC, Basile B. wrote:

 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.


 For `if (auto x = expr)`, the scope of `x` includes the 
 *ThenStatement*.
 For `if ((auto x = expr) || b)`, `x` can have similar scope.
 For `if (b && (auto x = expr))`, `x` can have similar scope.
 I think the above two cases could be supported in D.


Probably but trust me, allowing the declaration as an expression 
really solves the problem in a clean way.


 For `if (b || (auto x = expr))`, `x` may be uninitialized if it 
 is accessible in the *ThenStatement*. Does Styx forbid that and 
 similar cases?


No, such cases are allowed because locals are default 
initialialized before the `if`. It is then up to the programmer 
to test again if `x` is set to a particular value but at least is 
guaranteed not to be undefined.

Otherwise the only restriction (checked during a semantic pass) 
is that the declaration needs to be between parens if used as 
AndAnd or OrOr operand, as otherwise the operand can become part 
of the LHS initializer.

```
if var a = getA() && var b = getB() do {} // parse but sema error
if (var a = getA()) && (var b = getB()) do {} // ok
```

And in case the intention was really to have a single expression 
as condition.

```
if var a = (getA() && (var b = getB()) do {}
```


 Also for `if (b || ((auto x = expr) && x.b))`, `x` is safely 
 used but it may be uninitialized if its scope extends to the 
 *ThenStatement*.


Yes but this is considered as a programming error.
Aug 11 2023
prev sibling parent reply Basile B. <b2.temp gmx.com> writes:
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.
Aug 11 2023
next sibling parent reply Basile B. <b2.temp gmx.com> writes:
On Saturday, 12 August 2023 at 01:41:55 UTC, 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:

 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;

is indeed nice. Problem in my opinion is that this is just 
another special case.
In-situ var decls are nicer. They solve many problem in one shot.
Aug 11 2023
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 8/12/23 03:54, Basile B. wrote:

 On Saturday, 12 August 2023 at 01:41:55 UTC, 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:

 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;
 
 is indeed nice.


Yup.


 Problem in my opinion is that this is just another 
 special case.


`(auto x, auto y) = t;` is also a special case, because if this works, 
why shouldn't `foo(auto x, auto y) = t`. Just add an "injective" 
function qualifier and implement a simple type checker for that. Let's 
stuff it into the tuple DIP as well. Why stop there? This is just a 
special case of cascaded pattern matching. /s

If you are going to use the word "special case" in this abstract and 
overly wide fashion, then every feature is a special case by virtue of 
being separate from other features. You then can't at the same time 
pretend it's a problem. `a + b` being addition except `2 + 3 = 6` is a 
problematic special case. This is not similar to that. It's nice syntax, 
with an entirely standard and entirely obvious meaning, simple to parse.
`(auto x, auto y) = t` is needlessly noisy if you are going to infer the 
types for both variables anyway. It's also the form for which my parser 
is still incomplete.


 In-situ var decls are nicer.


There is not even a conflict. As I said, I agree that they may be a 
nicer implementation of the `(auto x, auto y) = t` syntax, although 
similarly hard to parse, and now in a much wider context. I am still 
entirely unwilling to get into the nitty-gritty details of the general 
feature within a tuple DIP, because my focus is on tuples and I am 
already strapped on time.

At this point, as well as from the start, I would be ecstatic if the 
_only_ additional thing that got implemented into the language was 
simple `auto (x, (y, x)) = t`-style unpacking. However, it's impossible 
because people are not able to agree on using the standard syntax for 
this unless there is a "full tuple design" that clarifies the "D way of 
doing tuples". Now you are piling on even more of this unpragmatic 
scope-expanding thinking without any benefit beyond satisfying some 
clearly misguided "special case" ideology. I would understand your 
concern if the tuple DIP made your feature impossible, but it just does not.

Also, you are probably going to fight an uphill battle because, among 
many other issues, Walter will be concerned about parse speed and 
stability if you have to attempt to parse every subexpression as a 
declaration first. Then there are cases like

foo(T* b = &x, b);

It's a huge rabbit hole. Your feature would likely be more than half of 
the tuple DIP, the DIP discussions would revolve around this feature by 
a large part,


 They solve many problem in one shot.
 
 


Well, they don't solve that particular problem, which was my point. This 
is actually the thing I primarily care about.



Don't get me wrong, lack of in-situ variable declarations is in my 
experience a recurring minor annoyance when writing D code.

It is annoying because of the following case, and in my experience 
basically only the following case:

```d
T x; // have to specify type here


// a is necessary precondition to call f(b)
if(a && (x=f(b)){ // assignment instead of initialization
     ...
}else{
     // x visible here
     ...
}
// x visible here
```

The pattern above is reasonable to want, but then due to the various 
drawbacks you should probably factor the code in a different way 
instead. In-situ variable declarations have the potential to solve that, 
but I really don't see why you want to allow them to escape disjunctions.
Aug 12 2023
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 8/12/23 03:41, 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:

 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.


I am not sure what you are saying. Both `auto (x, y) = t;` and
`(auto x, auto y) = t;` literally do already work with my prototype 
implementation.
Aug 12 2023
prev sibling parent Sergey <kornburn yandex.ru> writes:
On Tuesday, 8 August 2023 at 16:47:25 UTC, Vijay Nayar wrote:
Python libraries like PyTorch

 turn to C++. Perhaps this could be D instead.


This is not going to happen, because language is not suitable for 
that.
Aug 10 2023