if trailing LWSP is allowed, leading LWSP should be allowed, too. I
don't mind making such a change. I don't mind making the other changes,
either (including 1*HEXDIG).
Trailing and leading white space would be great indeed, because together
with LWSP you could encode a regular hexdump.
I don't think we have consensus to allow for comments.
I think we have consensus for not allowing them.
Just looking at ${hex:...} and ${unicode:...}, I really don't need them,
but should that syntax (enriched by something to split arguments) be
used for functions, I disagree with Ned on not needing comments for that.
I did use comments to comment arguments given to functions in the past,
but I admit it's like once every few years.
But... I don't insist on comments. Go ahead with LWSP and without comments.
Alexey: Could you please include an example that shows "${hex:" means
literally that and it is not an error? We can discuss that being right
or wrong, but at this time, everybody but me considers is being right
and that needs to be documented more clearly.
Btw: If you want to encode "${hex:00}" literally, you need to write
"${hex:24 7b 68 65 78 3a 30 30 7d}". "\$\{\h\e\x\:\0\0\}" is a string
with one NUL byte, plus lacking the good reason to abuse \ asked for
by the SHOULD NOT in section 2.4.2. I suppose everybody already knew
that, because the spec says, expansion happens after scanning a string.
If it surprises anybody, please speak up.
Hmm. 2.4.2 says further:
NUL (US-ASCII 0) is not allowed in strings.
How about:
An unencoded NUL (US-ASCII 0) is not allowed in strings, see section
2.4.2.4 for encoded characters.
Michael