>Viktor's point, which I think applies to Haskell and Rust, is that if the >library is updated with a new ENUM, because the new type has been added, >then >applications which do not have that in their case will fail to compile. > >Now, this is solveable with a match _ (in Rust. I don't know Haskell well) >in the application. However, if the application was handling type "4" >(AMTRELAY) via the bag-of-bytes for the old library [via match "sum", maybe >], >then when support is added, it can also break. Is this all solveable with >more work? Yes. > >What this amounts to, however, is that the application now has to make sure >it's bullet-proof for these types, rather than depending upon a well tested > library.
It very much depends on what the application expects to happen. In the case of RRtypes, ENDS(0) options, SVCB parameters, we do expect new ones to show up over time. So there is typically no point in doing a match on the enum. No application is expected to handle all cases. A program like 'dig' is an exception, but there is no point in optimizing for that category. In the case that started this discussion, Viktor expects that no new variant will ever show up. In that case a match is perfectly fine. If something new does show up, the application fails to compile. But that's a good thing as now an assumption has been violated. The interesting case is where an application supports a type that the library doesn't. In our case (domain crate) the user can supply a user defined type to the iterator method (for records in a DNS message, for EDNS(0) options, for SVCB parameters). Then the raw data data will be parsed by the user's own type and changes to the library have no effect. Just parsing every item into the unknown variant will also work and is also stable. These iterators are a lot of hassle to implement in the library, but for users it is mostly fine. There are a few other considerations. But in my experience, the hard part is knowing what part of a application needs to be extensible. When you know what data you need, it is usually easy enough to call the right library functions to get it. Coming back to the original point, for a libarary it doesn't really matter if code point allocation is first come, first served, expert review, or standards action. Anything that is not explicitly maintained by IANA can still be changed with a new RFC. So new things will show up. Libraries break backward compatibility in some cases. Applications may have to adapt. _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
