Fixed with a4140a3 , tests needed
> On 24 Dec 2015, at 09:28, Zefram (via RT) <perl6-bugs-follo...@perl.org>
> wrote:
>
> # New Ticket Created by Zefram
> # Please include the string: [perl #127019]
> # in the subject line of all future correspondence about this issue.
> # <URL: https://rt.perl.org/Ticket/Display.html?id=127019 >
>
>
> I'm not sure what identities we can expect coercions to obey in Perl 6,
> but this combination of coercions sure looks surprising:
>
>> True.^does(Numeric)
> True
>> True.^isa(Int)
> 1
>> True.Numeric
> 1
>> True.Int
> True
>
> The two coercions are surprisingly inconsistent. In both cases the output
> of the coercion isa Int, and the type to coerce to includes all of Int,
> so one would think that, having found a satisfactory Int to coerce to,
> the same Int would be the output of both coercions. But they differ.
> Apparently True isn't Numeric enough to be the output of a coercion,
> despite it being Int enough, when that's a more specific type.
>
> Furthermore, in this case the input value is already of both of the
> types to which it is requested to coerce. In this situation, it is
> surprising that a coercion produces any result different from the input.
> There is no work for the coercion to do.
>
> The Numeric coercion shown above is also inconsistent with what is
> obtained from a coercing type constraint:
>
>> (sub (Numeric() $a) { $a })(True)
> True
>
> The coercion that looks inconsistent with the others and with common
> sense is True.Numeric. If you're serious about Bool being a subclass
> of Int, surely True.Numeric needs to return True. (Overall it would be
> more sensible for Bool to have no particular relation to Int and Numeric,
> though. The subclass arrangement is detrimental to type discrimination
> and to correctness.)
>
> -zefram