3 ms·
Why would it be difficult to retrofit? It’s just a new set of types. Is it that existing APIs wouldn’t be using them?
by nicoburns 5y ago
Why would it be difficult to retrofit? It’s just a new set of types. Is it that existing APIs wouldn’t be using them?
- masklinn 5y ago> Why would it be difficult to retrofit? It’s just a new set of types. Is it that existing APIs wouldn’t be using them? It's a brand new kind which wouldn't necessarily work the way existing types do, and it's a whole lot of extra syntax. Plus previous retrofits have not exactly panned out great, C++ and Java's native "type safe enumerations" are pretty crummy as they're closer to enumerated sets of constants than sum types. Sealed classes/interfaces/traits/… fit well in the machinery and aesthetics of RTTI-heavy products-types-based languages and slot nicely into the "niche" of sum types.
- tialaramex 5y agoOne problem beyond the technical "How" is that culturally Go didn't have Sum types, so there are existing APIs where, if a Sum type was possible that's what you'd do, but it wasn't, so they didn't. This isn't so different from the problem Generics introduce (why isn't this API generic, oh, it pre-dates that feature). And it might similarly be worth it for Sum types, but it's certainly an extra consideration. On the technical side, Sum types kinda suck unless you have niches. If your Optional sum type is always actually bigger than the Some type it is wrapping then why even bother? So then you're also adding promises about niches in your implementation.