It would be really nice to be able to avoid null pointers by construction. But providing opt-in null pointers would require option types.
Option types can be seen as a special case of sum types (tagged unions) but without needing an explicit definition for each unique type. I like Ceylon's generalization, which lets one use types like int|bool.
One interesting idea here is that anonymous unions are to sum types as tuples are to product types. The only wrinkle: it seems natural to refer to the variants of an anonymous union by type (you can't have int|int), but tuples by position ((int, int) is a common use case).
I'm also thinking about Rich Hickey's criticism of Haskell, that it should be possible to pass in an int to a function that expects an int|bool. That requires checking types based on their structure rather than their names.
But I'm reluctant to permit passing in a type point3D to a function expecting a point2D just because the member names are a superset. Perhaps structure should only be checked for anonymous types.
Should we be able to pass in anonymous types anywhere the language expects a type? In members of user-defined types? Any constraints seem surprising.
By now we're well in the territory of features that I'm not sure will have much adoption. Just because I wanted to provide clean concepts without surprising limitations.
I'm curious to hear where others would draw the line. How much of this seems reasonable, and how much excessive architecture astronaut-ism?
This post is part of my Freewheeling Apps Devlog.
Comments gratefully appreciated. Please send them to me by any method of your choice and I'll include them here.