From @masak

<moritz_> masak​: can you submit the 'my Int $x = +"2"' bug please?
* masak submits
<masak> rakudo​: my Int $x = +'2'
<p6eval> rakudo 35875​: OUTPUT«Type mismatch in assignment. [...]
<jnthn> rakudo​: say WHAT +"2";
<p6eval> rakudo 35875​: OUTPUT«Numâ�¤Â»
<jnthn> meh.
<jnthn> That's why.
<moritz_> it should be a bit smarter
<masak> moritz_​: + numifies.
<masak> it doesn't intify.
<jnthn> masak​: I know, but it's not the most helpful behavior...
<masak> true.
<jnthn> Well, the most dwim anyway.
<moritz_> masak​: right. But since Int conforms to the Num type, it's
more DWIM if it does int directly, where appropriate
<moritz_> rakudo​: my Int $x = int "2";
<p6eval> rakudo 35876​: RESULT«2»

From @pmichaud

On Thu Jan 22 02​:48​:08 2009, masak wrote​:

<moritz_> masak​: can you submit the 'my Int $x = +"2"' bug please?
* masak submits
<masak> rakudo​: my Int $x = +'2'
<p6eval> rakudo 35875​: OUTPUT«Type mismatch in assignment. [...]
<jnthn> rakudo​: say WHAT +"2";
<p6eval> rakudo 35875​: OUTPUT«Numâ�¤Â»
<jnthn> meh.
<jnthn> That's why.
<moritz_> it should be a bit smarter
<masak> moritz_​: + numifies.
<masak> it doesn't intify.
[...]

Just to keep the ticket up to date, there was more discussion about this
at http://irclog.perlgeek.de/perl6/2009-02-28#i_946107 .

This discussion led to a new "numish" rule added to STD.pm, and we
expect that prefix​:<+> for string types will be smart enough to choose
Num or Int (and possibly Rat or Complex) based on the string it
numifies. The details may need to be fleshed out a bit further, though.

Pm

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

From @masak

<masak> rakudo​: my Int $a = 4 - 3; say $a; my Int $b = "4" - 3;
<p6eval> rakudo 748771​: OUTPUT«1â�¤Type mismatch in assignment. [...]
<masak> is it just me, or does this feel a bit harsh?
<mberends> it's p5ish
<masak> how is variable typing p5ish?
<mberends> in "4" - 3 the operator coerces to a number, but maybe not in P6
<masak> yes.
<masak> but Num !~~ Int.
<mberends> oh. I been bitten by that before as well.
<masak> I'd argue that if 4 - 3 works, then "4" - 3 ought to as well.
<mberends> yes, therefore it is harsh

From @kyleha

This is an automatically generated mail to inform you that tests are now available in b/t/spec/S03-operators/numeric-context.t

From @bbkr

[16​:02] <bbkr> rakudo​: (+"1").WHAT.say # is that a bug? IMO should be Int
[16​:02] <p6eval> rakudo 0e5edb​: OUTPUT«Num()â�¤Â»
[16​:08] <PerlJam> bbkr​: How is perl to know?
[16​:11] <bbkr> PerlJam​: probably same as "say 0.0" prints "0" - Num can be
narrowed to Int
[16​:13] <PerlJam> bbkr​: but, it does look like a bug. From the spec regarding
prefix​:<+> ... "For values that do not already do the C<Numeric> role, the
narrowest appropriate type of C<Int>, C<Rat>, C<Num>, or C<Complex> will be
returned"

From @bbkr

[16​:18] <PerlJam> rakudo​: (+"2/5").WHAT.say # broken t oo
[16​:18] <p6eval> rakudo 0e5edb​: OUTPUT«Num()â�¤Â»

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

From @moritz

Str.Numeric (which prefix + calls) now properly DWIMs, and returns Int,
Rat or Num as appropriate. Tested to great lengths in S32-str/numeric.t.

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