Hi - On 2022-04-09 4:36 AM, Christian Hopps wrote: ...
FWIW, I'm not arguing for this change; however, to be fair, isn't this also about the existing published modules that are using the incorrect type?
No. "Incorrect type" is a bit of a mischaracterization. It's like saying using "int32" is incorrect if all that is needed is "uint16". One might say its a little sloppy or mutter "RTFM" under one's breath, but it's not "incorrect." Some modules have used a type that potentially can represent more values than are needed for the intended purpose. Whether those implementations will ever accept or produce those values will depend on whether the code, whether library, generated, or hand- crafted, enforces the tighter constraints appropriate to the usage or only the looser constraints appropriate to the type's specification. But this is also true of every usage of any type where the use can only exhibit a subset of the possible values of the type, whether that subsetting is obvious from the description or not, so I find it really hard to get excited about it. The more nuanced a repertoire of types becomes, the more likely developers won't use exactly the right one, though one would hope that these foibles are caught during the review process, at least until developers start reading the documentation for the libraries they employ. Even in these cases of "incorrect" usage, as Andy and others have pointed out, stuff still works, because those cases only require a subset of the values supported by the type. If the proposed change is made, usages requiring the full value space of the original type definition will break, and those formerly "incorrect" usages will exhibit no change in their behavior. That is, the proposed change does not improve operation of anything, and it breaks some things. For me, it's more important for stuff to work (and to not break stuff) than it is to align perfectly with the underlying aesthetics of some naming system attributed post hoc to a set of types. Randy _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
