Tcl Source Code

There is no "binary" encoding.  At the script level it was always just iso8859-1, and always will be.  This is not an implementation detail leaked to the script level, just the fact that at the script level there is no "binary" mode, and that "binary" was always just an ill-advised synonym for iso8859-1.  At the script level there is only Unicode text, and if one wishes to manipulate "binary" data, one must in principle translate each incoming byte into the corresponding Unicode code point (even if internal optimizations like bytearray elide this step).  If each character in the text has a code point of 255 or less, it is amenable to interpretation as bytewise numerical values (binary).


In Tcl 8.6, configuring the translation of a channel as binary and then checking configuration yields a translation of "lf", not "binary", and this has always worked just fine.  The same should be true for encoding:  Programmers should understand that "binary" means iso8859-1 (assuming binary isn't removed as an encoding).

If anyone is writing code that is relying on whether the encoding for a channel is "binary", their code is probably buggy, and it probably would be less buggy if Tcl had never provided "binary" as an encoding option in the first place.  Binary data can come in through just about any encoding.  It doesn't make much sense to condition code on whether the channel encoding is "binary".

There is sufficient introspection available already.  There is no need for a [chan isbinary], and it would be a bad idea to provide it.  It generally makes more sense not to introspect the encoding, and instead to just set the encoding to what it is expected to be. I would like to see the use case for introspecting encoding.

The best course of action would be to eliminate "binary" as an encoding, since it never really was one, and leave "binary" only as an argument to -translation.