4 ms·
I haven't written it at all, but the Pony language showed up here on hackernews a while ago, and it has the kotlin solution except the notion that the variable
by rzwitserloot 7y ago
I haven't written it at all, but the Pony language showed up here on hackernews a while ago, and it has the kotlin solution except the notion that the variable isn't yet initialized is type-carried there. You couldn't 'fake out' the process and observe a null on a non-null variable there.
In other words, with some type system antics you can have your cake and eat it too, and that makes 'rust did this right', without also tacking on a deep dive on why pony's approach also has downsides, disingenuous or ill informed. (which I'm sure it does; my point is, this article doesn't cover it).
- matklad 7y agoSorry if the post reads like “rust did this right”: my intention was to show different trade offs around static/dynamic checking of constructors. I didn’t mean to argue that certain approaches are right, and others are wrong. In particular, the section about Swift shows that you can fully statically checked constructors if you dedicate enough language machinery to it. I don’t know a lot about Pony, but it seems like it uses a strict subset of Swift’s rules? There’s no inheritance so two phased initialization is condensed to “don’t call methods until all fields set”. It’s also not possible to call one constructor from another, so designated/convenience constructor split is also absent.