"Nick Sabalausky" <a...@a.a> wrote in message news:ieji3n$10o...@digitalmars.com... > "Walter Bright" <newshou...@digitalmars.com> wrote in message > news:iejejo$pf...@digitalmars.com... >> Nick Sabalausky wrote: >>> Any problem with the other Scala/C#-style one?: >>> >>> (x, y) => x * y >>> >>> // Lowered to: >>> >>> (x, y) { return x * y; } >>> >>> (Maybe that was rejected before due the the weird float operators that >>> are now being ditched?) >> >> The problem with the (x,y) parameter lists, where x and y are the >> parameters, is that it is ambiguous with the existing syntax of (x,y) >> where x and y are types and the parameters are omitted. >> >> For example: >> >> void foo(int); > > But we already have: > > (x, y) { return x * y; } > > So either there aren't any problems with it after all, or D's existing > delegate syntax is already broken. > > To be clear, with what I'm trying to suggest, the *only* thing that would > be different from the current delegate literal syntax is that part *after* > the parameter list. Ie: > > PARAM_LIST_HERE { return x * y; } > // --> > PARAM_LIST_HERE => x * y > > Or if there's a problem with =>, then ->, or -->, or ::>, or :>, or > whatever. I'm not suggesting the param list be different in any way > fromhow t is now. (Although proposals from other people might differ.) >
Slight correction: There is *one* other difference from the current delegate literal syntax: The part after => must be an expression rather than a statement or a block. But again, I'm not suggesting any change to param list - except *maybe* to make the param's parens omittable for zero-param or one-param delegates, but *only* if there isn't a problem with that. I'm ok with keeping them if they really still need to be there in those cases.
