On Tue, Mar 12, 2019 at 11:08:15AM -0700, Paul Ramsey wrote:
>> On Mar 12, 2019, at 9:45 AM, Paul Ramsey <pramsey@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