"lurker" <l...@lurk.net> wrote in message news:ie8rji$283...@digitalmars.com... > Nick Sabalausky Wrote: > >> "Jacob Carlborg" <d...@me.com> wrote in message >> news:ie8f5f$o6...@digitalmars.com... >> > >> > Probably not, but, for example, Scala allows very compact delegate >> > literals: >> > >> > Array(1, 2, 3, 4, 5).select(_ > 3).collect(_ * _) >> > >> > Or more verbose: >> > >> > Array(1, 2, 3, 4, 5).select((x) => x > 3).collect((x, y) => x * y) >> > >> > I'm not 100% sure I that the syntax is correct. >> > >> >> I'd be surprised if the first one is correct, because that "collect(_ * >> _)" >> would seem highly limited (how would you use the same value twice, or use >> just the second value, or use them in reverse order?). >> >> The second one reminds me of C#'s lambdas and seems like an excellent >> solution to the question of what to do with all the noise of the extra >> curly >> braces, "return" keyword and trailing semicolon. And given that 1. The => >> isn't currently a valid D token anyway, and 2. The (x) and (x,y) are >> already >> being used perfectly fine by the existing delegate literal syntax, I >> can't >> imagine there would be any ambiguity with it in D. >> >> I'd be absolutely in favor of adding that to D. In fact, I'd love to see >> it >> happen. Just require that the part after "=>" is an expression, accept >> that >> the more complex delegates that need statements use the existing syntax >> (which should be fine since it's only the >> single-expression-and-nothing-else >> delegates that are seen as verbose in D), and call it a day. > > => would make D look like Perl or PHP or Ruby.
If it's added to D, then it would be part of D, and would therefore look like D :) > Statements are more general than expressions, the D's solution is more > general. How much the short new syntax matters if you need two syntaxes > for it?! Would mean 2 function syntaxes, 2 delegate syntaxes. Two things > was already complex for users. Not entirely bad points, but C# doesn't seem to have a problem with it. Granted, I'm more in the "provide a variety of tools and let the user choose" camp than the "there is one true answer" one.
