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.

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.