On Tue, Mar 12, 2019 at 11:08:15AM -0700, Paul Ramsey wrote: >> On Mar 12, 2019, at 9:45 AM, Paul Ramsey <pram...@cleverelephant.ca> wrote: >> I was going to say that the function is only used twice in the code >> base, but I see it’s now used four times. So maybe leave the old >> signature in place and add the new one for my purposes after >> all. Though with only four internal calls, I am guessing Michael is >> more concerned about external users than with internal ones?
Yes, external tools are the part I worry about. It is better to avoid breaking compatibility if there are workarounds we can apply. Now I agree that this particular one may not be the most used ever in the community ecosystem. > So… > - two signatures? > - old signature but reduced error checking? > - elephant? I have not looked at how much effort it would be to keep the current API and still make the slicing happy, sorry ;p One way to sort things out would be to have a new _extended() API layer which is able to take a set of custom flags with one extra argument, using bits16 for example. This way, your new option becomes a flag in an extensible set, and we don't need to worry about breaking the API again in the future if more options are added. -- Michael
signature.asc
Description: PGP signature
