H2, > On 14 Aug 2018, at 1:38 PM, h...@abula.org wrote: > IMHO, there is an ever so subtle difference between navigation - using the . > operator explictly or implicitly (as with indexing) - and arithmetic.
do please correct me if I am wrong, but I understand in Groovy, arithmetic should be just a convenience thin syntactic sugar over messages; e.g., “a+b” should be full equivalent to “a.plus(b)”, but for the syntactic inconvenience: http://docs.groovy-lang.org/latest/html/documentation/#Operator-Overloading To me it seems rather unlucky and inconsistent that although I can write “a?.plus(b)”, I can't do precisely the same with its more convenient “a+b” equivalent. With other operators it is even more important, e.g., “a<<b”, which, in my experience, is used much more often as a shorthand for something like “a.append(b)” with generic objects a and b than as a numeric shift. > I am personally perfectly happy for my arithmetic expressions to fail with > any applicable exception if I throw unacceptable values at them. As for the (in)convenience of NPE vs null-propagation (or, in other words, (un)acceptability of nulls inside expressions), I guess it would rather be in the eye of the beholder. Do please note though I am not suggesting to remove the possibility to rely on NPE which you cherish, nor I am suggesting even changing the default behaviour in the slightest; what I would like to see in Groovy would be a way to intentionally switch to the non-NPE null-propagating behaviour where needed by very explicit using of an appropriate annotation. You, of course, would never be forced to use the thing :) Thanks and all the best, OC > Den 2018-08-14 13:28, skrev ocs@ocs: >> Gentlemen, >> some NPE-related problems of today brought me to re-interate one of my >> older suggestions. >> We have the so-called “safe navigation”[*], which in some cases allows >> a null to be propagated out of an expression instead of throwing a >> NPE. At the moment, it can be triggered for a particular >> sub-expression (like property/method-call and, as of 3, newly also >> indexing) using a question mark (e.g., “foo?.bar()” or “foo?[bar]”). >> Do please correct me if I am wrong, but far as I know, there still are >> expressions which do not allow the “safe mode”, e.g., arithmetic >> (“a+b” etc). Furthermore, there are cases when one simply wants a >> bigger block of code to contain only null-propagating expressions and >> never NPE; in such case, using the question mark syntax is both >> inconvenient and error-prone (for it is very easy to forget one of the >> lot of question marks needed in such a code, and then get an uncaught >> unwanted NPE). >> For these reasons, I would suggest adding a new annotation, whose name >> might be e.g., “ImplicitSafeNavigation”; it would simply force a >> null-propagation to be implicitly and automatically used for *all* >> expressions in the annotated scope, i.e., NPE would never be thrown >> for them; for example: >> === >> @ImplicitSafeNavigation class Foo { >> static foo(a,b,c,d,e) { >> a.bar+b*c[d]<<e.bax() // just e.g.; would work with *any* >> expression which NPEs today >> } >> } >> assert null == Foo.foo(null,null,null,null,null) >> === >> I wonder whether this enhancement would be possible to implement in >> some forthcoming Groovy release? Myself, I believe it would help >> tremendously. >> If feasible, then it is for a further discussion whether in the scope >> of this annotation >> (a) a safe-navigation syntax (“foo?.bar”) should be ignored as superfluous; >> (b) or, whether in this scope it should reverse the behaviour to >> trigger an NPE anyway; >> (c) or, whether it should be ignored as (a), and aside of that it >> would be worth the effort (and technically possible) to add another >> syntax to force NPE over a particular sub-expression (e.g., >> “foo!.bar”). >> Thanks and all the best, >> OC >> [*] The name might not be quite apt, for propagating a null is not >> inherently safer than NPEing; those are simply two different >> approaches, both of which serve best in different circumstances. A >> better name would be something like “null-propagating” or “non-NPE” >> mode, I guess. Myself, I don't think we should change the name though, >> for all are used to it.
