Just a followup:

> On 14 Aug 2018, at 2:25 PM, ocs@ocs <o...@ocs.cz> wrote:
> 
> 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.

... considering that, instead of a simple annotation, one with a boolean 
parameter to switch the behaviour on and off as needed might be better:

===
@ImplicitSafeNavigation(true) 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
  }
  @ImplicitSafeNavigation(false) bar(a) {
    a.bar
  }
}
assert null == Foo.foo(null,null,null,null,null)
Foo.bar(null) // throws NPE
===

> Begin forwarded message:
> 
> From: "ocs@ocs" <o...@ocs.cz>
> Subject: suggestion: ImplicitSafeNavigation annotation
> Date: 14 August 2018 at 1:28:01 PM CEST
> To: dev@groovy.apache.org
> Reply-To: dev@groovy.apache.org
> 
> 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.
> 

Reply via email to