This operation doesn't seem to work.   It would be a pretty handy thing to work since we don't support named parameters at this time.

Comments?

On Friday, 24 July 2015 at 14:12:39 UTC, Shammah Chancellor wrote:
> This operation doesn't seem to work.   It would be a pretty handy thing to work since we don't support named parameters at this time.
>
> Comments?

This limitation could probably be lifted easily.

But I fail to see the relation to named parameters?

On Friday, 24 July 2015 at 14:48:30 UTC, Marc Schütz wrote:
> But I fail to see the relation to named parameters?

You can make your parameters into a struct or tuple and fill them in with normal assignment. The with(auto) thing will conveniently limit the scope of the temporary argument object and give a bit of syntax sugar for it:

with(auto args = ParameterTypeTuple!foo) {
   argname = cool;
   argname2 = whatever;
   foo(args);
}


.....ironically, given the other thread about statements as expressions where i said 'meh', this is actually a decent case for them too, to get the return value of foo out of that scope while still allowing auto.

But that's a separate issue, the main point here is just that you can use it to prepare the arguments with a bit of sugar.

On Friday, 24 July 2015 at 15:01:29 UTC, Adam D. Ruppe wrote:
> On Friday, 24 July 2015 at 14:48:30 UTC, Marc Schütz wrote:
>> But I fail to see the relation to named parameters?
>
> You can make your parameters into a struct or tuple and fill them in with normal assignment. The with(auto) thing will conveniently limit the scope of the temporary argument object and give a bit of syntax sugar for it:
>
> with(auto args = ParameterTypeTuple!foo) {
>    argname = cool;
>    argname2 = whatever;
>    foo(args);
> }
>

Nice!

On Fri, 24 Jul 2015 14:12:39 +0000, Shammah Chancellor wrote:

> This operation doesn't seem to work.   It would be a pretty handy thing to work since we don't support named parameters at this time.
> 
> Comments?

https://issues.dlang.org/show_bug.cgi?id=13526

On Friday, 24 July 2015 at 15:01:29 UTC, Adam D. Ruppe wrote:
> On Friday, 24 July 2015 at 14:48:30 UTC, Marc Schütz wrote:
>> But I fail to see the relation to named parameters?
>
> You can make your parameters into a struct or tuple and fill them in with normal assignment. The with(auto) thing will conveniently limit the scope of the temporary argument object and give a bit of syntax sugar for it:
>
> with(auto args = ParameterTypeTuple!foo) {
>    argname = cool;
>    argname2 = whatever;
>    foo(args);
> }
>
>
> .....ironically, given the other thread about statements as expressions where i said 'meh', this is actually a decent case for them too, to get the return value of foo out of that scope while still allowing auto.
>
> But that's a separate issue, the main point here is just that you can use it to prepare the arguments with a bit of sugar.

The with statement is one where I think it would be interesting to make it an expression.

For named parameters (admittedly, I find this one a bit ugly):
foo(with(ParameterTypeTuple!foo) {
    abc = 2,
    def = 3
});

Or just:
auto args = with(ParameterTypeTuple!foo) {
    abc = 2,
    def = 3
};
foo(args);


For initialization:
auto a = with(new FooBar()) {
    name = "Foo",
    bar = 3
};

Or:
with(new Thread(&foo) {
    isDaemon = true
}).start();

On Sunday, 26 July 2015 at 07:28:45 UTC, Kapps wrote:
> On Friday, 24 July 2015 at 15:01:29 UTC, Adam D. Ruppe wrote:
>> [...]
>
> The with statement is one where I think it would be interesting to make it an expression.
>
> For named parameters (admittedly, I find this one a bit ugly):
> foo(with(ParameterTypeTuple!foo) {
>     abc = 2,
>     def = 3
> });
>
> Or just:
> auto args = with(ParameterTypeTuple!foo) {
>     abc = 2,
>     def = 3
> };
> foo(args);
>
>
> For initialization:
> auto a = with(new FooBar()) {
>     name = "Foo",
>     bar = 3
> };
>
> Or:
> with(new Thread(&foo) {
>     isDaemon = true
> }).start();

Sadly it'll break all the code that currently use it, since we'll now need to terminate it with a semicolon.

On 07/26/2015 01:04 PM, Idan Arye wrote:
> On Sunday, 26 July 2015 at 07:28:45 UTC, Kapps wrote:
>> On Friday, 24 July 2015 at 15:01:29 UTC, Adam D. Ruppe wrote:
>>> [...]
>>
>> The with statement is one where I think it would be interesting to
>> make it an expression.
>>
>> For named parameters (admittedly, I find this one a bit ugly):
>> foo(with(ParameterTypeTuple!foo) {
>>     abc = 2,
>>     def = 3
>> });
>>
>> Or just:
>> auto args = with(ParameterTypeTuple!foo) {
>>     abc = 2,
>>     def = 3
>> };
>> foo(args);
>>
>>
>> For initialization:
>> auto a = with(new FooBar()) {
>>     name = "Foo",
>>     bar = 3
>> };
>>
>> Or:
>> with(new Thread(&foo) {
>>     isDaemon = true
>> }).start();
>
> Sadly it'll break all the code that currently use it, since we'll now
> need to terminate it with a semicolon.

Well, no. That does not follow. We can have both a with statement and a with expression.

On Sunday, 26 July 2015 at 14:49:40 UTC, Timon Gehr wrote:
> On 07/26/2015 01:04 PM, Idan Arye wrote:
>> On Sunday, 26 July 2015 at 07:28:45 UTC, Kapps wrote:
>>> On Friday, 24 July 2015 at 15:01:29 UTC, Adam D. Ruppe wrote:
>>>> [...]
>>>
>>> The with statement is one where I think it would be interesting to
>>> make it an expression.
>>>
>>> For named parameters (admittedly, I find this one a bit ugly):
>>> foo(with(ParameterTypeTuple!foo) {
>>>     abc = 2,
>>>     def = 3
>>> });
>>>
>>> Or just:
>>> auto args = with(ParameterTypeTuple!foo) {
>>>     abc = 2,
>>>     def = 3
>>> };
>>> foo(args);
>>>
>>>
>>> For initialization:
>>> auto a = with(new FooBar()) {
>>>     name = "Foo",
>>>     bar = 3
>>> };
>>>
>>> Or:
>>> with(new Thread(&foo) {
>>>     isDaemon = true
>>> }).start();
>>
>> Sadly it'll break all the code that currently use it, since we'll now
>> need to terminate it with a semicolon.
>
> Well, no. That does not follow. We can have both a with statement and a with expression.

Mmm... but how will we differ them? The style in Kapps' example can fit into Rust, but looks weird in D. How about something that resembles the difference between expression and block lambdas:

    with (...) { ... } // statement with
    with (...) => ... // expression with

While it may differ from lambdas since in lambdas both are expressions, it's similar in that the version without the => accepts a block of statements and the version with the => accepts an expression.

On 07/26/15 17:56, Idan Arye via Digitalmars-d wrote:
> On Sunday, 26 July 2015 at 14:49:40 UTC, Timon Gehr wrote:
> Well, no. That does not follow. We can have both a with statement and a with expression.
> 
> Mmm... but how will we differ them?

There's no need for that. (hint: "mixin"). But, unlike
support for with-declarations (which would be a significant
improvement) I'm not sure if with-expression would make
sense (and the lifetimes might be too unintuitive --
they'd be different for with-statements and -expressions).

artur