I have a question - why are the lengths 30, 62, 126, instead of 31, 63, and 127 (and if there were a UInt2048, 255)?

[xiaodaigh]

I have a question - why are the lengths 30, 62, 126, instead of 31, 63, and 127 (and if there were a UInt2048, 255)?
The max size length (in bytes) for any of those is just one byte (2 nibbles).
Also, since characters are only encoded in 1 or more bytes, the length could be just expressed as bytes, unless you want to use an extra nibble to store other information about the short string (which might be useful).

Originally posted by @ScottPJones in #22 (comment)

[ScottPJones]

After looking more at the code, I think it's really due to a bug in the code, the code is mixing bytes and nibbles.
If the package had a hard limit of 255 bytes for ShortStrings, then it could be simplified to always use just a single byte.

[oxinabox]

If the package had a hard limit of 255 bytes for ShortStrings, then it could be simplified to always use just a single byte.

It doesn't though.
I have used it for much longer strings, and it works.
It just means using BitInteger.jl to make larger integers.

[ScottPJones]

OK. For fixed size strings, generally I haven't seen greater than 255 (and that's for old legacy database fields, where they liked to have fixed size fields for everything, i.e. CHAR(255))

[ScottPJones]

I'd kind of like to add ShortString255 by default - given how frequently I've seen that in database schema

[xiaodaigh]

Just a comment. I think if ppl want to use it, then I think we can create an easy to use macro as suggested before where the number at the end is not necessary. It will figure it out and homogenize it in an array for the user automatically.

[ScottPJones]

That's going to be one of my next steps (as I know @oxinabox wants it!)
A version of ShortString(string, maxlen) that will construct a ShortString based on maxlen,
as well as ss"foo" that will do ShortString(string, sizeof(string)).

[ScottPJones]

This has now been resolved by #31