Community
Participate
Working Groups
Some suggested additional operator overloadings: a:b // would allow JSON like DSL more easily, amongst others a|b // allows for piping syntax, would be really nice a? // would be very nice for option type programming for example a?b // nice in combination with a? a! // just nice, no real case yet :-) a% // 50% :-) a@b // for addressing DSL a::b // addressing @a // addressing ~a // addressing a~b // addressing a\b // addressing a[b] // now that would be tough.. but powerful. array like objects possible However not all fit the Xtend syntax, so needs checking what is feasible.
*** Bug 405637 has been marked as a duplicate of this bug. ***
(In reply to Christian Vogel from comment #0) > a:b // would allow JSON like DSL more easily, amongst others conflicts with several expressions (e.g switch) > a|b // allows for piping syntax, would be really nice conflicts with lambdas > a? // would be very nice for option type programming for example > a?b // nice in combination with a? > a! // just nice, no real case yet :-) conflicts with !a > a% // 50% :-) > a@b // for addressing DSL > a::b // addressing conflicts with old-style static access > @a // addressing conflicts with annotations, especially when we are going to add type annotations (JSR 308) > ~a // addressing > a~b // addressing > a\b // addressing > a[b] // now that would be tough.. but powerful. array like objects possible conflicts with lambdas.
More suggestions: Elvis operator variations (with a question mark), in order to be able provide more functionality, while not having to overload the original elvis operator. Like: ?% and ?* And more assigning kind of operators, like: <~ and ~>
And, I know it wouldn't be possible right now, but maybe in the future: turning ?. into an operator.
(In reply to Floris van der Grinten from comment #4) > And, I know it wouldn't be possible right now, but maybe in the future: > turning ?. into an operator. Could you pleas elaborate on the use case? Usually it's a bad idea to implement another semantics for an operator that is well understood and associated with a defined behavior.
(In reply to Sebastian Zarnekow from comment #5) > Could you pleas elaborate on the use case? Usually it's a bad idea to > implement another semantics for an operator that is well understood and > associated with a defined behavior. And that is the exact reason I would like to have elvis variations like ?* and ?%. But about the null safe feature (?.), that could be used really nicely with optionals. So same semantics, but working with an implementation of optionals. I would like to see something like this: val Opt<String> someString = someOtherOptString?.toLowerCase // returns an optional either way But like I said, for now having ?* and/or ?% would be really good already.
I'd like to use more symbolic operators to overload and define, both binary and unary (infix, prefix) For example, I'd like to: e1 | e2 e1 |= e2 e1 & e2 e1 &= e2 e1 ^ e2 e1 ^= e2 e1 ^^ e2 e1 ^= e2 e1 %= e2 e1 **= e2 e1 ?:= e2 e1 !: e2 e1 !:= e2 e1 <<= e2 e1 >>= e2 e1 <<<= e2 e1 >>>= e2 Unary: %e1 ~e1 @e1 Postfix derived from prefix: e1~~ (does: e1 = ~e1) e1!! (does: e1 = !e1) etc. In general, it would be ideal if there wasn't a restriction on which symbols you can use, and for binary, how many there can be in a row. This would allow operators like %!!$~#, ∩, ≅ or ∊. Related: #476778 #413818
