Tcl Source Code

> I would expect "-translation" to give back "binary" in stead of "lf" here, then that can be used to check for binary mode.

Huh, so you'd expect still one additional backwards incompatibility in 9.0?

"-translation binary" did never set itself to "binary", it was solely a setter for grouped setting -encoding binary -translation lf -eofchar {}. Nothing else.

I don't think Tcl really needs a change like that.

There is indeed no encoding binary, but the channel may be binary, so why still not consider it like in 8.x as binary encoding? And a setting this via translation is a bit different to me: it'd also change eofchar and translation, what is correct for pure binary mode of channel, however if one uses something like:

chan configure -encoding binary -eofchar {}

So why not just "revert" back to the 8.x handling for consistency and just accept pseudo encoding name binary for binary mode retaining translation as it is?

Let alone iso8859-1 is never comparable with binary mode, because one prefers strings another bytearrays (and for example strictly seen iso8859-1 has to reject all chars 0x00-0x1F and 0x7F-0x0F), so it is still more confused then (and previous handling of 8.x. remaining binary as value is more consistent).

Why having an artificial encoding name (what is not really an encoding just a mark for bytearray handling) is so bad? Take a look at unicode - it is also not existing encoding, but just a mark for unicode handling, nothing else. But the name is pretty usable.

> Many people use "-encoding binary" while they really mean "-translation binary".

This is not an argument in my opinion:

1. RTFM
2. In case of "backwards compatibility vs. theoretical possibility for typo" we shall always prefer the first, because...
3. If one would consider arguments like that, then let us forbid everything what can introduce a confusion (hardly possible in a script-lang, especially in that with EIAS model) and ignore every compat question in the future.

So I'd just switch back to 8.x handling: binary is valid value that can be set with -encoding parameter similar to unicode (which is also unknown encoding, rather a sign we'll work internally with unicode string instead). But as already said, I'd really use binary as return value (instead of iso8859-1)... again, similar to 8.x, to unicode pseudo encoding, and pretty backwards compatible.

I agree that current situation is confusing, and like Harald, have no clear opinion, just some thoughts.

If we were starting from scratch, I would have liked to stick to the principle that setting one option should never silently change another option as -translation does today. If you want the low level options (eof, encoding, translation) that are required for binary mode, set them via fconfigure yourself, or use the simple "open b" method. However, changing -translation to not modify eof and encoding settings would now be too disruptive, so that's not an option.

That leaves the question of what to do about -encoding binary. Leaving it in the current state means

• fconfigure $chan -encoding returns a different value (iso8859-1) from what was set (binary). This gives me a bit of discomfort.
• This is a (small) incompatibility with Tcl 8.

If changed as Jan suggests,

• It is consistent in that there is really no encoding called "binary" and there is no question of fconfigure returning a different value than was set.
• This is also incompatible with Tcl 8, though in a different, probably more common and therefore serious, manner than above.

A third option, not necessarily one I favor, but throwing it out there, is to make -encoding binary a synonym for -translation binary so it would also change eof and line-ending settings.

• This in theory is the most incompatible with 8.6 but could actually most compatible in practice. Code that is using it will likely be also changing eof and line-endings and if not, should have been doing so and is probably broken code that would be fixed.

The second option (Jan's) seems cleanest but my gut feel is that the first and third options will cause the fewest compatibility problems. With the second option, correct code "fconfigure $chan -encoding binary -translation lf -eofchar {}" will now fail.

So...mixed feelings and not very helpful comments! If I were really pushed, I would keep things as they are (with a release note) but only because at this particular moment I lean towards compatibility over cleanliness :-)