Re: nil encoding as synonym for binary encoding

Yukihiro Matsumoto wrote:
> Hi,
> 
> In message "Re: nil encoding as synonym for binary encoding"
>     on Sat, 12 Jan 2008 03:04:00 +0900, David Flanagan <[e-mail]> writes:
> 
> |I don't understand.  Are you saying that in the current implementation 
> |set_encoding(nil) is different than 
> |set_encoding(Encoding.default_external) and also different than 
> |set_encoding(Encoding::BINARY)?  What does it do, then?
> 
> set_encoding(nil) - default
>   * read encoding - Encoding.default_external
>   * write encoding - anything, no check
> 
> set_encoding(Encoding.default_external)
>   * read encoding - Encoding.default_external
>   * write encoding - check whether default_external
> 
> set_encoding(Encoding::BINARY)?
>   * read encoding - Encoding::BINARY
>   * write encoding - check whether Encoding::BINARY
> 
> See?

That makes it much clearer, at least to me.

"check whether Encoding::BINARY" is a bit of a surprise to me.  Every 
string of bytes can be interpreted as binary.  So what you are saying 
(and I verified it with a test) is that you are checking to see if the 
data is already MARKED as Encoding::BINARY.  Hmmm.

And you describe similar check for default_external.  That concerns me 
more.  If I read data off of the web, or retrieve data from a database 
that is iso-8859-1, and simply wish to write it to a file where 
default_external is utf_8, will Ruby do what I expect (i.e. convert it), 
or simply throw an exception?

I would have instead expected "check whether" to be "transcode to" in 
the above descriptions, and errors only be thrown when such transcodings 
are not possible.

Furthermore, having nil do something different on read and write, add to 
that the observation that no matter what it does, somebody is going to 
be surprised; and it seems like it would be best if nil weren't 
supported.  Particulary if "no check" and "transcode to 
Encoding::BINARY" amount to the same thing.

- Sam Ruby