Steve Yegge's rant on The Next Big Language

[Jarrett Billingsley]

"BCS" <BCS at pathlink.com> wrote in message 
news:eqst20$29s$1 at digitalmars.com...
>
> Yes that would be nice, but it is one hell of a can of worms. It has more 
> corner cases than general cases. About the only things that would be safe 
> and reasonably understandable would be to put the whole stack frame on the 
> heap.
>
> If someone can figure out how to fix all the problems in a reasonably 
> understandable manner, I'd love to see it. Until then, I think Explicit 
> scoping (using structs) is the way to go.
>
> Again, just my opinion.

That's why it's Walter's job ;)

> Would this count?
>
> struct foo{int x=1; int y=1;}
>
> void fn(foo f){...}
>
> fn({x:0});
> fn({y:0});
>
> not as nice, but with a little tweaking we could have this:
>
> void fn(struct {int x=1; int y=1;}){...}
>
> use an anon struct as the arguments.

Someone actually suggested this.  Basically the idea was that if your 
function took a struct as a parameter, you could replace the struct with a 
list of struct member initializers and D would implicitly create the struct.

struct foo { int x = 1; int y = 1; }
void fn(foo f) { ... }
fn(x:0, y:5);

basically the same as your suggestion but without the curly braces at the 
call site.

I'd like to see something, anything, for named parameters.  I still think 
the compiler should be able to map directly to the function's named 
arguments without any extra trickery like using a struct.