RFC: 2 enhancement DIPs that need feedback (page 2)

On 5/20/25 11:59, jmh530 wrote: > On Tuesday, 20 May 2025 at 09:33:40 UTC, Dejan Lekic wrote: >> On Tuesday, 13 May 2025 at 09:04:07 UTC, Basile B. wrote: >>> >>> ```d >>> (auto a, auto b) = call(); // two VarDeclExp in the LHS >>> ``` >> >> Please no... If we can't have `auto (a, b) = call();` then we better not have it at all... > > Why not allow both? > > Both variants work with the design proposed in the DIP, but Basile's alternative proposal by default would allow at most one of these, which is what Dejan was objecting to.

On 5/14/2025 9:56 AM, Timon Gehr wrote: > Go ahead and implement it. It's harder, not a simplification. Suddenly, whenever you are parsing any expression, you will have to take into account the possibility that it is actually a variable declaration. The way DMD deals with lvalues is also ill-equipped to allow this to be added easily. Furthermore, you now have to do proper scope handling for short-circuiting operations. There's also a problem with handling destruction of the declaration.

{ MyStruct ms0; // def init, ms0 is in valid state MyStruct ms1; // def init, ms1 is in valid state if (ms0 = call0) && (ms1 == call1) {} // ... // right before the end of the scope ms0.__dtor(); ms1.__dtor(); }

May 23

Re: RFC: 2 enhancement DIPs that need feedback

Posted by Basile B.
in reply to Basile B.

Permalink

Basile B.

Posted in reply to Basile B.

Permalink

On Thursday, 22 May 2025 at 09:31:51 UTC, Basile B. wrote:

On Wednesday, 21 May 2025 at 04:55:50 UTC, Walter Bright wrote:

On 5/14/2025 9:56 AM, Timon Gehr wrote:

Go ahead and implement it. It's harder, not a simplification. Suddenly, whenever you are parsing any expression, you will have to take into account the possibility that it is actually a variable declaration. The way DMD deals with lvalues is also ill-equipped to allow this to be added easily. Furthermore, you now have to do proper scope handling for short-circuiting operations.

There's also a problem with handling destruction of the declaration.

I dont think so. I consider that, based on default initialization, which has to always happen, even if an AndAnd

OrOr

LHS has evaluated to true and then that the RHS is a VarDeclExp, then its matching variable is always destructible.

To be clear the AST for

if (MyStruct ms0 = call0) && (MyStruct ms1 == call1) {}

is to be thought as

{
    MyStruct ms0; // def init, ms0 is in valid state
    MyStruct ms1; // def init, ms1 is in valid state
    if (ms0 = call0) && (ms1 == call1) {}

if ((ms0 = call0) || (ms1 == call1)) {}

// ...
// right before the end of the scope
ms0.__dtor();
ms1.__dtor();

}


In practice that scenario almost never happen, since VarDeclExp are 99% of the time used for pointers or simple numeric types.

plus do people often use opCast!bool ?

Forums