"Martin Nowak" , dans le message (digitalmars.D:145287), a écrit : >>> 4. The expression is badly delimited. >>> The first rewrite symbol => expression >>> is actually symbol => expression\{CommaExpression, CatExpression}. >>> >>> E.g.: >>> dgs ~= (int a) => (a + 5) ~ (int a) => (a ^^ 2);
this is a compile time error, because you are appending an int (a+5) with a delegate ((int a) => (a^^2)). You should write : dgs ~= [(int a) => a + 5), ((int a) => a ^^ 2)]; >>> foo(a, b => (log(b), b), c) That seems fine to me. > sort!((a, b) => a <= b)(input) > vs. > sort!((a, b) { a <= b })(input) OK > > static assert ((a, b) => a < b != (a, b) => a > b) That is a compile time error too, because you use != on a boolean on one side, and on a delegate on the other side. You have to use parenthesis arround the delegates to use an operator on them, otherwise the operator could be a part of the delegate. static assert (((a, b) => a < b) != ((a, b) => a > b)) > vs. > static assert ((a, b) {a < b} != (a, b) {a > b}) OK > Another minor issue: > a => > a + 3 > Offers worse indentation for long expressions than > (a) { > a + 3 > } Why? > We won't remove the existing function literal syntax due to code breakage. > We won't remove the string predicates because they are still shorter. > I am worried about having three subtly different language constructs for > the same concept. > > (a, b) { return a < b; } | q{a < b} | (a, b) => a < b > | old delegate syntax | string predicates | fat arrow delegates > |-------------------------------------------------------------- > scope | declaration | instantiation | declaration > return | explicit | implicit | implicit > body | statements | expression | expression > types | optional | no | optional > Don't forget the return-omissing delegate syntax (a, b) { a < b } :P Old delegate should be kept as the normal way to build a delegate. They are needed to make more than one-liners. Maybe optional types might be removed in the long term to make the language simpler, but they can't be removed. In the long term (D>=3.0, not to break existing code), I am not sure it is worth keeping string predicates if delegates offer a convenient syntax. Moreover they are not a langage feature, they are a library feature. Nothing prevents people from writing a dozen syntax like that. -- Christophe