Chapel 1.20: Offer to help with nilability changes

[Brad C. <br...@cr...>]

Hi Chapel Programmers —

As many of you may know from our State of the Project presentation at 
CHIUW 2019, one of the main things that the Chapel team is currently 
focused on is getting the language to the point that we can minimize, if 
not eliminate, backwards-breaking changes in future releases for a core 
set of language features.  To that end, we are working towards making next 
month's 1.20 release of Chapel the release candidate for what we've been 
referring to as Chapel 2.0.  You can read more about this concept in the 
slides from CHIUW:

 	https://chapel-lang.org/CHIUW/2019/CHIUW2019-Welcome-SoP.pdf


Getting to that release candidate and its intended feature set has 
necessarily involved some growing pains in the name of improving the 
language.  Examples from recent releases include the move from 
constructors to initializers, and the introduction of managed class types. 
This upcoming release features one more similarly significant change 
(along with several smaller ones), which is to distinguish between class 
variables that can store 'nil' and those that cannot.

Briefly, the idea behind this concept is as follows:  Historically, given 
a class 'C', a variable 'var myC: C = ...' could either store 'nil' or 
point to an object of type 'C'.  In the new world (enabled by default on 
master yesterday), a variable of type 'C' will not be able to store 'nil' 
by default.  Instead, the type specifier 'C?' indicates the case where a 
variable may refer to either 'nil' or an instance of 'C'.  New syntax like 
'myC!' can be used to assert/check that 'myC' is non-nil (halting if it's 
not).

Needless to say, this is a fairly large change for code that uses classes, 
although one that we think is worthwhile given that it promotes safer 
coding by default, can reduce the need for nil-checking in many cases, and 
increases awareness of where nil dereferences may occur at compile-time.

Given the impact of this change on Chapel code that uses classes, we 
wanted to offer up-front to help any users with transitioning their 
existing Chapel code from 1.19 to 1.20 — either by helping to work through 
the changes if your code can be shared, or by being even more available 
than usual to answer questions if not.

If this help would be of interest to you, please reply to this mail and 
let me know.

On behalf of the Chapel team at Cray,
-Brad Chamberlain