I don't feel strongly about this either way. String-pad is definitely a precedent, but there is also the CL lexical syntax, which allows an optional integer literal between # and * and makes it an error to write #5*100100. (The last bit is used as the padding bit.)
On Sun, Aug 27, 2023 at 7:30 PM Shiro Kawai <[email protected]> wrote: > The description is not clear when the length argument is smaller than the > length of given bitvector; "... elements equal to _bit_ added (if > necessary)" seems only to consider adding elements, while "...so that the > length of the result is _length_" indicates the length of the result should > always match the length argument, implying that the input can be truncated. > > The string counterpart, string-pad in srfi-13, does truncate input when > the length argument is smaller than the length of the input object. For > consistency, I think bitvector-pad should behave in the same way. > > An easy correction may be to say ""... equal to _bit_ added or removed (if > necessary) ...". > > If it is agreed, I can send PR, with fix in the reference implementation > and test code. > > --shiro > >
