October 13
On 10/13/21 4:41 PM, Paul Backus wrote:
> On Wednesday, 13 October 2021 at 19:18:55 UTC, Andrei Alexandrescu wrote:
>> The point is that with keeps the entire expression live, even if you only care about a part of it:
>>
>> struct S { int x; ... }
>>
>> with (auto y = S().x)
>> {
>>    ...
>> }
>>
>> In this case the S() temporary will be destroyed only at the end of with's scope.
> 
> Not a fan. It uses the same syntax as `if (auto y = S().x)` but has subtly different semantics, in a way that's likely to go unnoticed in common usage.

Yah, good point. Prolly it would be good to find a reasonable way to extend the lifetime of the temporary in a more general case.

October 13
On 10/13/21 4:13 PM, Timon Gehr wrote:
> On 10/13/21 1:13 PM, Andrei Alexandrescu wrote:
>> We can improve the `with` statement as follows:
> 
> I don't think this is an "improvement" of the `with` statement. It's a completely novel feature that happens to be syntactically very close to the existing `with` statement. There's an obvious meaning for the new syntax as an extension of the existing feature, but it is not what you propose. Not great. Maybe there is a better way to address this problem?

You're right. The `while (type)` and `while (type):` at top level is probably good to salvage.
October 14

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

>

On 10/13/21 4:13 PM, Timon Gehr wrote:

>

On 10/13/21 1:13 PM, Andrei Alexandrescu wrote:

>

We can improve the with statement as follows:

I don't think this is an "improvement" of the with statement. It's a completely novel feature that happens to be syntactically very close to the existing with statement. There's an obvious meaning for the new syntax as an extension of the existing feature, but it is not what you propose. Not great. Maybe there is a better way to address this problem?

You're right. The while (type) and while (type): at top level is probably good to salvage.

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.

October 14

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

>

Maybe having the syntax as:

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

Would be better?

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 could also be useful in Python style management for file handles

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");
}
>

, plus be visually distinct enough from other uses of with to not simply be overlooked.

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);
}
October 14

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

>

We have an awkward idiom in the dmd source code:

https://github.com/dlang/dmd/search?q=extendedPathThen
https://github.com/dlang/dmd/search?q=toWStringzThen

It's a tail wagging the proverbial dog. Clearly we could do with better ways. We can improve the with statement as follows:

  1. Accept named with:

with (auto xpath = extendPath(name)) {
// the only name injected here is xpath
}

All destructors for the expression involved in with are called AFTER the with is done.

  • 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

October 14

On Thursday, 14 October 2021 at 07:12:29 UTC, Tejas 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.

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.

October 14

On Thursday, 14 October 2021 at 08:44:27 UTC, Antonio 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

I sometimes use std.functional.pipe for this:

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

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

>

On Thursday, 14 October 2021 at 07:12:29 UTC, Tejas 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.

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.

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?

October 14

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

>

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

>

[...]

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

[...]

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

October 14

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

>

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

Yes.

>

Is this proposed extension merely syntax sugar, then?

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.

Next ›   Last »
1 2 3