On Fri, Feb 22, 2019 at 10:54:10AM -0600, Eric Blake wrote: > 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. Yes interface{} is a clever trick serving a vaguely similar purpose to allowing a 'void*' in C, but with benefit that the method can actually do some real type checking. The downside is that this is now runtime type checking, not static compile time. So I think on balance I'd still prefer the static checking and accept the breakage, as it is a win in the long term with only small amount of short term pain. > > 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). Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
