Ryan Lortie <desrt <at> desrt.ca> writes: > We need to figure out what our story is with respect to annotations. > 'Rename to:' is an extreme example (since an entire function, as named, > disappears) but we can easily cause problems just as serious with > changes that look a lot more innocent (like changing array length > parameters or such). We can even break vala bindings with the > introduction of an (allow none). > There's been a bunch of changes that people have often done to stable APIs in various projects and have been happy that this works without problems. Examples that I can remember off the top of my head include: - constifying arguments to functions (in particular strings) - allowing NULL inputs - changing void return values to booleans (or even ints) - adding arguments to vfuncs (not signals, regular vfuncs) - renaming arguments
And there's probably a bunch of other even uglier things that people enjoy doing. And I'd be very unhappy if those would get even more restricted than ELF already makes them for us. So I'd take a very hard look at Vala and wonder if disallowing nullability changes isn't a bug in Vala. That said, if things like this were introduced, I'd want a tool to check for this. Because when people in C start passing NULL before the Vala guys figure out that that breaks their applications, we have a big problem. And the only way to not have this happen is by a tool telling us "you are breaking API" - preferably during make, but at the latest upon make distcheck. Benjamin _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list