RE: NPE's - I have a feeling that'll be abused just like void * and interface{}. People will just start throwing Nil around everywhere as a catch-all. You need

RE: NPE's - I have a feeling that'll be abused just like void * and interface{}. People will just start throwing Nil around everywhere as a catch-all. You need a stronger construct like Option<T>, Maybe, language-level nullable types, or a mechanism for the caller to handle it dynamically (a la unwind-protect/conditions). The problem you end up getting is basically the dual of the 'expression problem'. You get easy type expandability with class augmentation by these semantics, but any client of the type is subsequently bound to deal with any augmentation of the type. (I.e., if in the method defining class 'a', you insert an elseif in between the consequent and the alternative of type Bool, you now just extended the class signature of 'a' to Int32 | String | Bool. Assuming all consumers of 'a' need exhaustive handling, you've opened your class and extended its functionality at the expense of code which had previously satisfied the dependencies to consume 'a' safely. Crystal still remains a real interesting project to follow. I haven't examined the Crystal type system too carefully, but the concept of Parent+ as virtual types is an interesting concept that is certainly worth exploring.