LTA IO::Handle.encoding can have a value, but no valid decoder is setup

[zoffixznet]

http://colabti.org/irclogger/irclogger_log/perl6-dev?date=2018-07-09#l155

Zoffix | We have a wart in IO::Handle. In its TWEAK, it sets $!encoding, but 
    that alone never sets up decoders
Zoffix | e: with class :: is IO::Handle {}.new { .encoding.say; .print: "foo"}
evalable6 | Zoffix,  rakudo-moar e93032a9a: OUTPUT: «(exit code 1) utf8␤Cannot 
    do 'print' on  a handle in binary mode␤ in block <unit> at /tmp/dbeuXgzaQW line  1␤␤»
Zoffix | probably can restructure and move the decoder creation to TWEAK, with .open not 
    bothering with it if it's already set

This issue has more significance for subclasses of IO::Handle that might not utilize .open calls.

[zoffixznet]

Tried fixing it by setting up the encoder in TWEAK, but then it breaks constructs like IO::Handle.new(:$path).open(:bin), and we could make .open unset the encoder if :bin is provided, but then we're setting up a decoder just to almost immediately throw it away.

A correcter approach might be to not set any options in .new, even if there are attributes. Maybe a long term goal would be to forbid IO::Handle.new calls entirely and require the :$path currently given to .new to be a positional argument of .open

http://colabti.org/irclogger/irclogger_log/perl6-dev?date=2018-07-11#l201

---

All of these issues likely apply to IO::CatHandle too, BTW.