On Thursday, 14 October 2021 at 02:58:32 UTC, Andrei Alexandrescu wrote:

Maybe having the syntax as:

with <construct> as <identifier>{
    //do stuff
}

Would be better?
It could also be useful in Python style management for file handles, plus be visually distinct enough from other uses of with to not simply be overlooked.

On Thursday, 14 October 2021 at 07:12:29 UTC, Tejas wrote:

with <construct> as <identifier>{
    //do stuff
}

This is completely novel syntax (for d), when the proposed syntax is used all over the place in d. How are you going to explain this to Scott Meyers, after his whole speech about "please don't make the decisions that require professional explainers like me"? https://www.youtube.com/watch?v=KAWA1DuvCnQ

It's not as nice but with and a scope both offer this (with a strace confirming that the file is closed before the writeln):

void main() {
    import std.stdio : File, writeln, stdout;

    with (File("/etc/passwd")) {
        stdout.write(readln); // std.stdio.write is shadowed by File
    }
    writeln("that's enough");
}

void main() {
    import std.stdio : File, writeln, write;

    {
        auto file = File("/etc/passwd");
        // at least there's no extra nesting for multiple files?
        write(file.readln);
    }
    writeln("that's enough");
}

but if we're adding syntax, how about something to make tuple deconstruction a little bit nicer? with already offers that but nobody's noticed in the other thread about what they'd like in d, because of how much work it is:

import std.stdio : writeln;
import std.typecons : Tuple;

unittest {
    struct S { int a; float b; }
    with (S(1, 2)) {
        writeln(a);
        writeln(b);
    }
}

auto opaque() {
    struct S { char a; ubyte b; }
    return S('a', 'b');
}

unittest {
    with (Tuple!(char, "x", ubyte, "y")(opaque().tupleof)) {
        writeln(x);
        writeln(cast(char) y);
    }
}

the proposed with(): would get rid of the nesting that's not wanted for tuple deconstruction, but naming could still be improved. How about borrowing from foreach?

unittest {
    with (char x, ubyte y; opaque): // implicit .tupleof
    writeln(x);
    writeln(cast(char) y);
}

On Wednesday, 13 October 2021 at 11:13:32 UTC, Andrei Alexandrescu wrote:

• I usually take the functional way:

(string xpath){		
  ...
}( expandPath(name) );

And UFCS doesn't help to "beutify" the code. This doesn't work (And, in my opinion, should):

expandPath(name).(auto xpath){		
  ...
};

This neither

expandPath(name).((auto xpath){		
  ...
})();

May be "with" could be an alternative

On Thursday, 14 October 2021 at 07:12:29 UTC, Tejas wrote:

with <construct> as <identifier>{
    //do stuff
}

In D this is accomplished using a regular block scope and a variable declaration:

{
    auto <identifier> = <construct>;
    // do stuff
}

Python needs special syntax for it because Python doesn't have block scopes--the only thing that introduces a new scope in Python is a function.

On Thursday, 14 October 2021 at 08:44:27 UTC, Antonio wrote:

(string xpath){		
  ...
}( expandPath(name) );

expandPath(name).(auto xpath){		
  ...
};

expandPath(name).((auto xpath){		
  ...
})();

I sometimes use std.functional.pipe for this:

expandPath(name).pipe!((auto xpath) {
    /* ... */
});

On Thursday, 14 October 2021 at 13:44:24 UTC, Paul Backus wrote:

with <construct> as <identifier>{
    //do stuff
}

{
    auto <identifier> = <construct>;
    // do stuff
}

So is it safe to say what Andrei wants can be accomplished with new block + with?

void main(){
    int a;
    struct S{ int d;}
    {
       S s;
       with(s){
         a = d;
       }
    }
}

I kinda remembered that Python can't introduce new scope arbitrarily when jfondren criticized my opinion as well.

Is this proposed extension merely syntax sugar, then?

On Thursday, 14 October 2021 at 08:37:40 UTC, jfondren wrote:

Timon's tuple DIP should've been worked on further and accepted ;(

On Thursday, 14 October 2021 at 13:50:29 UTC, Tejas wrote:

Yes.

Yes, but most syntax is syntax sugar. The main issue with it is that it's inconsistent with other, similar syntax sugar that's already in the language.