Lambda syntax, etc
Nick Sabalausky
a at a.a
Wed Feb 4 23:40:29 PST 2009
"BCS" <none at anon.com> wrote in message
news:a6268ff24108cb552c70a0af6c at news.digitalmars.com...
> Hello Nick,
>
>>> One #1 I'd be inclined to requier that the function be defined like
>>>
>>>> void DoIt(int delegate(int) dg...)
>>>>
>>> D laready has this syntax for Typesafe Variadic Functions
>>> http://www.digitalmars.com/d/1.0/function.html
>>>
>> I'm not quite convinced either way on this. For what reasons do you
>> think the function header should be required to indicate "this uses
>> block syntax"? What's wrong with just saying "If the last arg a
>> function takes is a delegate, then that delegate can optionally be
>> specified with block syntax."?
>>
>
> I have used bare block statements on occasion and a missing ';' in the
> wrong place would be nasty to parse. Another option for killing that
> problem would be to forbid overloading only on a trailing delegate so
> Foo(int) and Foo(int, int delegate()) would be considered ambiguous (that
> argues for the ... as then the rule would be to forbid overloading only on
> block delegates)
>
I think I see what you mean. Although, that does create an inconsistency
that bothers me a bit, because then some functions with trailing delegate
params could be called with block syntax and others couldn't. And then the
ones that can be called that way have a restriction on overloading and the
ones that can't, don't have that restriction. Just seems messy to me.
Maybe instead of requiring anything in the declaration, any use of the block
statement style could be required to include a paramater list (and
disallowing block statement style for varargs):
void foo(int a) {/*stuff*/}
void foo(int a, void dg(void)) {/*stuff*/}
// Ok
foo(5, { writefln("hi"); } );
// Ok, calls foo(int)
foo(5);
{ writefln("hi"); }
// Illegal (because of [1]) *even* if the
// "foo(int)" overload doesn't exist
foo(5)
{ writefln("hi"); }
// Ok, calls foo(int, void delegate(void))
foo(5)
(void)
{ writefln("hi"); }
// Illegal, because of [2]
foo(5);
(void)
{ writefln("hi"); }
// [1]: Already Illegal:
// (However, this would become ambiguous with [3],
// but that could be solved by block-statement-style
// being disallowed for varargs)
writefln("hi")
{ writefln("hi"); }
// [2]: Already Illegal? (Or is it a "verb-less"
// delegate literal expression statement?):
(int a)
{ writefln("hi"); }
// [3]
writefln("hi", {writefln("hi");} );
This way, it's impossible to take valid code, add or remove a semicolon, and
still have valid code (which I think was your main concern?).
More information about the Digitalmars-d
mailing list