Does `--fast` disable any nil-checks that `C!` will generate? Has overhead been measured?
What would an array of `var A : [D] C` contain by default? Why not make all types nil-able by default and make nil-ability an opt-in feature? Get Outlook for Android<https://aka.ms/ghei36> ________________________________ From: Brad Chamberlain <[email protected]> Sent: Friday, August 23, 2019 2:06:41 PM To: Chapel Users Mailing List <[email protected]>; Chapel Sourceforge Developers List <[email protected]>; Chapel Educators Mailing List <[email protected]> Subject: [Chapel-developers] Chapel 1.20: Offer to help with nilability changes 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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchapel-lang.org%2FCHIUW%2F2019%2FCHIUW2019-Welcome-SoP.pdf&data=02%7C01%7C%7Cd52c4343bcf04d52460008d727f4c2ae%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637021804499571266&sdata=TFq3Vkp%2BQBo%2FJ7Os9DindCwXoejoC2IJIPv0YBotyoM%3D&reserved=0 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
_______________________________________________ Chapel-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-developers
