Max

> what's missing? While `tobinary` would be catering to 8-bit string processing (where the indexing operations work as in C, Go, Rust), it might also be worth adding something that...

> But even here we'd be stepping on the Unicode Consortium's toes -- it would be much much better, but also much much harder, to get the UC to allocate...

> That works provided other systems understand it I think the purpose of any such encoding should only be for internal use. Except for debugging purposes, it should preferably not...

> Agreed, "tobytearray" and "toutf8" are unreadable at best and unacceptable at worst, so I was wondering what alternatives there might be. An underscore? camelCase? Or better, something with a...

> A `tobinary16` would produce a string of 16-bit code units which when _output by jq to stdout/stderr_ would be base64-encoded, but which _during the jq program's execution_ would actually...

> Equality is trivial (a byte comparison) I don't think reducing equality to byte comparison will ever be desirable. This will only work if string and bigint values are either...

The keying function idea seems a bit awkward to me, because it's possible that the keying function will return different values for the same original key over time (eg, `k...

> I personally believe it actually should be the only accepted return values of keyBy, to avoid potential footguns like you describe. How does that avoid the footgun? Presumably `k...

> My expectation is that a keying function would only ever be called once for any given value, and the result memoized. If that's taken literally, it means it would...

Just to add further commentary: personally, I think this would have been better than introducing the concept of "asynchronous functions" (and likewise, generator functions), since there was really no need...