On 2/22/19 10:43 AM, Daniel P. Berrangé wrote: > On Fri, Feb 22, 2019 at 04:32:27PM +0100, Erik Skultety wrote: >> Unfortunately, in order to support the new flags, the last patch introduces an >> API breakage as the convention we use for the bindings is to also enforce types >> for flags. > > Yes, unfortunately this need to break ABI is fallout resulting from > my decision to make the Go bindings do stricter enum validation that > we have had at the C level. > > On balance I think that is still the right tradeoff to have stronger > type checking as it catches real errors in app code. I'm fine with that decision. I will note, however, that this website suggests an interesting approach: http://changelog.ca/log/2015/01/30/golang A variadic function using ...interface{} can accept arbitrary types for the optional parameters, and then open-code its own type-checking to ensure that the user complied with the intended use-cases. If the flags parameter can be accepted through that type of trick, coupled with validation that the caller never passed more than one argument for flags, and that the passed argument is typed solely as one of the two expected enums, then you can maintain API compatiblity, even though the ABI changes to a variadic instead of a strictly-typed flags argument. I don't know if it is worth doing, though. > > Due to the widespread use of "vendoring" in the Go community where > apps fixate on specific git commit hashes of their dependandancies, > the fallout is more limited and will mostly only impact devs at the > time they decide to explicitly sync to newer git. > And this is a good argument for not being upset about the API break and therefore not worrying about trying to use variadic functions to give back-compat. (For the record, the nbdkit project specifically documents that its C API/ABI will be kept compatible, but warns that other language bindings API may break, precisely to account for cases like this where there is a mismatch between C semantics and the slightly different idioms of the other languages). -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
