• Adam D. Ruppe (42/42) Jul 23 2012 I was just thinking about porting a javascript function to
• FeepingCreature (2/15) Jul 23 2012 The more general form would be to make variable declaration an expressio...
• Adam D. Ruppe (3/5) Jul 23 2012 Right, and that would be pretty amazing, but it would probably
• Don Clugston (5/10) Jul 24 2012 The bizarre thing, however, is that the compiler uses it internally.
• deadalnix (3/18) Jul 23 2012 With the current grammar, it is difficult, because declarations are
• deadalnix (8/10) Jul 23 2012 Let's not add another special case for the declaration can be used here
• Adam D. Ruppe (6/11) Jul 23 2012 I don't think that's actually going to happen though.
• Chris NS (16/16) Jul 24 2012 I can't help thinking it sounds rather like a job for... named
• Adam D. Ruppe (5/7) Jul 24 2012 Yeah, that could do it too, but named parameters have been
• Chris NS (11/18) Jul 24 2012 Oh I know; which is why I wrote in a slightly snarky manner. I

"Adam D. Ruppe" <destructionator gmail.com> writes:

I was just thinking about porting a javascript function to
D that takes an object of params:

function foo(args) { ... }

foo( { "closeButton" : false, "width" : 200 } );


In D, I figured I'd make args a struct:

struct FooArgs {
    bool closeButton = true; // the default is for it to be there
    int width = 600;
}

void foo(FooArgs args) { ... }


And, of course, this works, but it was leaving a declared
variable around and can be somewhat repetitive. But first
I tried making it look kinda like the JS:

FooArgs args = { closeButton: false };
foo(args);

But, that style struct initializer doesn't respect the default
values. Here, width == 0. No good.


So, then, well, that's OK, I'll just write it out:

FooArgs args;
args.closeButton = false;
foo(args);



There we go, not too bad at all. We can kill some repetition
of "args" with the with() {} statement. Great!

But, what if I have another call later? I don't want that args
sticking around.


FooArgs args;
// ...
foo(args);

BarArgs args; // error, args already declared




No prob, let's scope it! I tried:


with(FooArgs args) {
    closeButton = false;
    foo(args);
}

// can redeclare another args here if you want


But it didn't work. It is with(symbol) or with(expression)
in the spec.



Would it work to also allow with(decl)? It seems to me that
it should be ok... kinda similar to the currently allowed

if(auto a = foo()) { /* use a here */ }


So we're just extending that same idea out to the with statement
too.

FeepingCreature <default_357-line yahoo.de> writes:

On 07/23/12 16:37, Adam D. Ruppe wrote:
 But it didn't work. It is with(symbol) or with(expression)
 in the spec.
 
 
 
 Would it work to also allow with(decl)? It seems to me that
 it should be ok... kinda similar to the currently allowed
 
 if(auto a = foo()) { /* use a here */ }
 
 
 So we're just extending that same idea out to the with statement
 too.

The more general form would be to make variable declaration an expression. I'm
not sure if that causes any ambiguity, parsing-wise, but it allows other neat
things as well, like while(vardecl) and if (decl1 && condition).

"Adam D. Ruppe" <destructionator gmail.com> writes:

On Monday, 23 July 2012 at 14:46:30 UTC, FeepingCreature wrote:
 The more general form would be to make variable declaration an 
 expression.

Right, and that would be pretty amazing, but it would probably
be too hard to do in D today...

Don Clugston <dac nospam.com> writes:

On 23/07/12 17:04, Adam D. Ruppe wrote:
 On Monday, 23 July 2012 at 14:46:30 UTC, FeepingCreature wrote:
 The more general form would be to make variable declaration an
 expression.

 Right, and that would be pretty amazing, but it would probably
 be too hard to do in D today...


The bizarre thing, however, is that the compiler uses it internally. 
There's thing called a DeclarationExp. It's created all the time when 
lowering occurs.
It"s only in the parser that declarations are not valid as expressions.

deadalnix <deadalnix gmail.com> writes:

Le 23/07/2012 16:46, FeepingCreature a écrit :
 On 07/23/12 16:37, Adam D. Ruppe wrote:
 But it didn't work. It is with(symbol) or with(expression)
 in the spec.



 Would it work to also allow with(decl)? It seems to me that
 it should be ok... kinda similar to the currently allowed

 if(auto a = foo()) { /* use a here */ }


 So we're just extending that same idea out to the with statement
 too.

 The more general form would be to make variable declaration an expression. I'm
not sure if that causes any ambiguity, parsing-wise, but it allows other neat
things as well, like while(vardecl) and if (decl1&&  condition).

With the current grammar, it is difficult, because declarations are 
statements.

deadalnix <deadalnix gmail.com> writes:

Le 23/07/2012 16:37, Adam D. Ruppe a écrit :
 I was just thinking about porting a javascript function to
 D that takes an object of params:

Let's not add another special case for the declaration can be used here 
instead of an expression. This is already the case in if and it will 
proliferate.

The real need here is to allow variable declaration to be used as 
expressions. And functions too as they are first class citizens now.

This reduces special cases instead of adding new one, and give a much 
greater opportunity for expressiveness in the language.

"Adam D. Ruppe" <destructionator gmail.com> writes:

On Monday, 23 July 2012 at 15:37:22 UTC, deadalnix wrote:
 The real need here is to allow variable declaration to be used 
 as expressions. And functions too as they are first class 
 citizens now.

I don't think that's actually going to happen though.
It is just a big, big change.

Adding with(decl) is a small change. I think anyway.

 This reduces special cases instead of adding new one, and give 
 a much greater opportunity for expressiveness in the language.

I agree this would be nice, but I'm just trying to ask
for something I think we can actually get...

"Chris NS" <ibisbasenji gmail.com> writes:

I can't help thinking it sounds rather like a job for... named 
parameters.  Just imagine it:


void foo ( bool closeButton = true, int width = 600 ) {
     writeln( closeButton, ", ", width );
}

void main () {
     foo( closeButton: false );
}


With output:
false, 600

Gosh, that'd sure be swell.  (Either that or find a way to sanely 
allow non-static struct initializers, at least for rvalue 
arguments.)

-- Chris NS

"Adam D. Ruppe" <destructionator gmail.com> writes:

On Tuesday, 24 July 2012 at 07:03:05 UTC, Chris NS wrote:
 I can't help thinking it sounds rather like a job for... named 
 parameters.  Just imagine it:

Yeah, that could do it too, but named parameters have been
brought up a few times too and there's opposition to it.

I kinda prefer the struct to named params anyway because
you can store it for later too. But I could go either way.

"Chris NS" <ibisbasenji gmail.com> writes:

On Tuesday, 24 July 2012 at 23:03:39 UTC, Adam D. Ruppe wrote:
 On Tuesday, 24 July 2012 at 07:03:05 UTC, Chris NS wrote:
 I can't help thinking it sounds rather like a job for... named 
 parameters.  Just imagine it:

 Yeah, that could do it too, but named parameters have been
 brought up a few times too and there's opposition to it.

 I kinda prefer the struct to named params anyway because
 you can store it for later too. But I could go either way.

Oh I know; which is why I wrote in a slightly snarky manner.  I 
still hold out hope.  Your reuse argument for structs is, of 
course, completely valid and compelling.

Another possibility, in cases like that presented in the original 
post, is to write a single struct to be used with all the 
relevant functions -- but then there's the problem of memory 
abuse.  In some cases it may be fine, but tossing around several 
copies of a very large struct, and only using two or three of the 
fields in a given case, is just unreasonable.

-- Chris NS