From @moritz

<moritz> m​: say 'ö'.encode('ASCII')
<camelia> rakudo-moar 7e8d8a​: OUTPUT«Blob[uint8]​:0x<3f>␤»
<moritz> that looks like a bug to me

Since ö isn't representable as ASCII, this should throw an exception.
Currently it encodes to 0x37, which is the question mark / replacement
character. Since using a replacmement character silently loses
information, which is a dangerous default.

Here is my wish list​:

1) the default is to throw an exception, let's say

  X​::Str​::NotEncodable.new(
  source => 'ö',
  index => '0',
  destination => 'ASII',
  );

2) if a replacment is desired, indicate that through an adverb in the
.encode call, either

  'ö'.encode('ASCII', :replacement)

to get the default, or

  'ö'.encode('ASCII'. :replacement(Buf.new(42)))

to be able to chose a replacement byte or byte sequence.

If somebody implements it, I'll add it to the design docs :-)

Cheers,
Moritz

From @jnthn

On Sun Jan 25 07​:35​:58 2015, moritz wrote​:

<moritz> m​: say 'ö'.encode('ASCII')
<camelia> rakudo-moar 7e8d8a​: OUTPUT«Blob[uint8]​:0x<3f>␤»
<moritz> that looks like a bug to me

Since ö isn't representable as ASCII, this should throw an exception.
Currently it encodes to 0x37, which is the question mark / replacement
character. Since using a replacmement character silently loses
information, which is a dangerous default.

Here is my wish list​:

1) the default is to throw an exception, let's say

 X​::Str​::NotEncodable\.new\(
     source => 'ö',
     index  => '0',
     destination => 'ASII',
 \);

2) if a replacment is desired, indicate that through an adverb in the
.encode call, either

 'ö'\.encode\('ASCII', :replacement\)

to get the default, or

 'ö'\.encode\('ASCII'\. :replacement\(Buf\.new\(42\)\)\)

to be able to chose a replacement byte or byte sequence.

If somebody implements it, I'll add it to the design docs :-)

The default is now to throw an exception (not typed for now), and the replacement functionality is available (though you specify it as a string, to ensure you can't replace with something that is bogus in the target encoding). ilmari++ for working on this; I'm just closing the ticket! Tests in S32-str/encode.t.

/jnthn

The RT System itself - Status changed from 'new' to 'open'

@jnthn - Status changed from 'open' to 'resolved'