August 10, 2023

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.

August 10, 2023

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, i.e something that's not especially made for tuples and that works as a normal primary expression.

August 10, 2023
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;`
August 10, 2023

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, 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.

August 11, 2023

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.

August 11, 2023
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.
August 11, 2023

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.

August 11, 2023

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.

August 12, 2023
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.
August 12, 2023

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, 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.