3 ms·

>Says who? The playground example (https://go.dev/play/p/R9dm6uYZSas?v=goprev https://go.dev/play/p/R9dm6uYZSas?v=goprev) is a great example. All single bytes

>Says who? The playground example (https://go.dev/play/p/R9dm6uYZSas?v=goprev https://go.dev/play/p/R9dm6uYZSas?v=goprev) is a great example. All single bytes, 0-255, print as the printable character or if non-printable as \x except 127. There's nothing special about 127 to deserve this. Inversely, \u denotes multibyte for all code points except 127. Once again, why is 127 special? There's two possible fixes: note that 127 is special (even without a reason, but at least document it), or change the behavior to align with everything else. UTF-8 itself was a response in part to perceived arbitrary decisions made in other encodings; I'm not surprised that the second fix was preferred. Our chief concern was how many bytes were used in encoding, and that's when we ran into this issue. If not fixed, our tests in our library had to notate why 127 is special (because Go says so), or hope for a change. Now that it's fixed, there's no need for downstream documentation. It's a minor change, but now no one else ever has to spend the time we took to look into this issue because now there are no surprises. That makes it worth it. >That's code point 127 How does that joke go? There's only two hard things in computer science...

morelisp 4y ago
So, says you, because it was aesthetically unpleasant for you. That's a far cry from "should always be... reserved for... must". Now we need to lockstep our team's version upgrade since I just learned some tooling will otherwise bounce it back and forth. "Thanks." > There's nothing special about 127 to deserve this. Other than the thing I said, which means it is now literally a special-case in the fmt code where it wasn't before.
- Zamicol 4y ago
  >Now we need to lockstep our team's version upgrade since I just learned some tooling will otherwise bounce it back and forth That sounds like an interesting issue. Could you perhaps go into more detail? >means it is now literally a special-case in the fmt code No. There is no special case, and the logic (literally) runs in the same switch case. https://go-review.googlesource.com/c/go/+/397255/4/src/strconv/quote.go#102 https://go-review.googlesource.com/c/go/+/397255/4/src/strco...
  - morelisp 4y ago
    Nah, if you believe - case r < ' ': + case r < ' ' || r == 0x7f: does not introduce a special case, I don't think we'll find any accord through discussion.
    - Zamicol 4y ago
      Yes this is minor semantics. Tab, carriage return, new line, etc.. are a special cases: https://go-review.googlesource.com/c/go/+/397255/4/src/strconv/quote.go#96 https://go-review.googlesource.com/c/go/+/397255/4/src/strco... Range selection is not a special case, and it's equivalent to writing it as `case r == 0x00, r == 0x01, r == 0x02 ... r ==0x7f`. The short hand, `r < 0x20`, is far more readable. I would reiterate, the lack of the need for another literal `case` shows that logically this is not a special case. In the sense of the abstract idea of ASCII, 0x7f is unique in its position, but so are all characters. There is no meaning in its positional placement in ASCII. It's totally arbitrary and was thought to be a useful convention. If position denoted other relevant, and unique, meaning to printing, then yes it could be a special case in certain circumstances. But its position has no additional information. And that's the key, no information means no special case.
      - morelisp 4y ago
        > There is no meaning in its positional placement in ASCII. It's totally arbitrary... This is also not true.

morelisp 4y ago

So, says you, because it was aesthetically unpleasant for you. That's a far cry from "should always be... reserved for... must". Now we need to lockstep our team's version upgrade since I just learned some tooling will otherwise bounce it back and forth. "Thanks." > There's nothing special about 127 to deserve this. Other than the thing I said, which means it is now literally a special-case in the fmt code where it wasn't before.

Zamicol 4y ago
>Now we need to lockstep our team's version upgrade since I just learned some tooling will otherwise bounce it back and forth That sounds like an interesting issue. Could you perhaps go into more detail? >means it is now literally a special-case in the fmt code No. There is no special case, and the logic (literally) runs in the same switch case. https://go-review.googlesource.com/c/go/+/397255/4/src/strconv/quote.go#102 https://go-review.googlesource.com/c/go/+/397255/4/src/strco...
- morelisp 4y ago
  Nah, if you believe - case r < ' ': + case r < ' ' || r == 0x7f: does not introduce a special case, I don't think we'll find any accord through discussion.
  - Zamicol 4y ago
    Yes this is minor semantics. Tab, carriage return, new line, etc.. are a special cases: https://go-review.googlesource.com/c/go/+/397255/4/src/strconv/quote.go#96 https://go-review.googlesource.com/c/go/+/397255/4/src/strco... Range selection is not a special case, and it's equivalent to writing it as `case r == 0x00, r == 0x01, r == 0x02 ... r ==0x7f`. The short hand, `r < 0x20`, is far more readable. I would reiterate, the lack of the need for another literal `case` shows that logically this is not a special case. In the sense of the abstract idea of ASCII, 0x7f is unique in its position, but so are all characters. There is no meaning in its positional placement in ASCII. It's totally arbitrary and was thought to be a useful convention. If position denoted other relevant, and unique, meaning to printing, then yes it could be a special case in certain circumstances. But its position has no additional information. And that's the key, no information means no special case.
    - morelisp 4y ago
      > There is no meaning in its positional placement in ASCII. It's totally arbitrary... This is also not true.