3 ms·

Huh, this is in interesting feature: https://crystal-lang.org/docs/syntax_and_semantics/union_types.html https://crystal-lang.org/docs/syntax_and_semantics/unio

by elihu 10y ago

Huh, this is in interesting feature: https://crystal-lang.org/docs/syntax_and_semantics/union_types.html https://crystal-lang.org/docs/syntax_and_semantics/union_typ... If you have code paths that set a particular variable to different types, it promotes the type of the variable to a union. I'm not convinced that's a good idea, but then I don't usually use dynamically typed languages; perhaps this is the most natural way to do static typing for people who come from languages like Ruby.

yxhuvud 10y ago
In practice, it accomplishes two things. It is the tool used to catch null pointer exceptions at the compile stage and it is what allows you to write duck typed interfaces.
- iheartmemcache 10y ago
  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.
  - RX14 10y ago
    Because crystal's nil type can have methods on, it already feels like an Option<T> with `#try`. We've had a lot of discussion about nil handling, but haven't come up with a better solution yet. Simple patterns like `return/raise unless foo` can protect the rest of a method body from nil without adding indentation.

by elihu 10y ago

yxhuvud 10y ago

In practice, it accomplishes two things. It is the tool used to catch null pointer exceptions at the compile stage and it is what allows you to write duck typed interfaces.

iheartmemcache 10y ago
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.
- RX14 10y ago
  Because crystal's nil type can have methods on, it already feels like an Option<T> with `#try`. We've had a lot of discussion about nil handling, but haven't come up with a better solution yet. Simple patterns like `return/raise unless foo` can protect the rest of a method body from nil without adding indentation.