www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - with(auto x = ...)

reply "Shammah Chancellor" <shammah.chancellor gmail.com> writes:
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?
Jul 24 2015
next sibling parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
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?
Jul 24 2015
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
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.
Jul 24 2015
next sibling parent "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
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!
Jul 24 2015
prev sibling next sibling parent reply "Kapps" <opantm2+spam gmail.com> writes:
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();
Jul 26 2015
parent reply "Idan Arye" <GenericNPC gmail.com> writes:
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.
Jul 26 2015
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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.
Jul 26 2015
parent reply "Idan Arye" <GenericNPC gmail.com> writes:
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.
Jul 26 2015
parent Artur Skawina via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
Jul 26 2015
prev sibling parent Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 07/24/2015 05:01 PM, Adam D. Ruppe wrote:

 
 .....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.


It would make sense to extend the if statement rule [¹] to with [²] and
switch [³].

[¹]: http://dlang.org/grammar.html#IfStatement
[²]: https://issues.dlang.org/show_bug.cgi?id=13526
[³]: https://issues.dlang.org/show_bug.cgi?id=11070
Jul 26 2015
prev sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
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.
=20
 Comments?


https://issues.dlang.org/show_bug.cgi?id=3D13526=
Jul 25 2015