From @AlexDaniel

Code​:
min(+'a', +'a').say

Result​:
Inf

Normally such conversion throws an error​:
Code​:
say +'a'

Result​:
Cannot convert string to number​: base-10 number must begin with valid
digits or '.' in '⏏a' (indicated by ⏏)
  in block <unit> at ./test.pl​:2

But that's not the case in min(). I'd probably accept any other result
(Error, 0, NaN, whatever), but not Inf.

From @coke

I agree that this should be throwing the same conversion error. Here's probably why it's giving Inf, though​:

$ perl6

say min()
Inf
say max()
-Inf

--
Will "Coke" Coleda

From @pmichaud

On Mon, Jun 08, 2015 at 06​:08​:33AM -0700, Will Coleda via RT wrote​:

I agree that this should be throwing the same conversion error.

I disagree to the extent that making min() throw the conversion error seems
to go against the purpose of designing soft/lazy Failure types into Perl 6
in the first place.

Sometimes we speak about not having the entire rocket explode simply
because of a few errors in the input set. In this case, min() is designed
to silently ignore undefined values in its calculations. Since in this
example all of the input values were undefined, min returned its 0-arg
case of Inf.

Perhaps an argument could be made that if min() is invoked on a list
consisting only of undefined values, it should return the first (undefined)
value instead of Inf. In other words, undefined values end up in this
middle-region between "lowest defined value" and "Inf", or something like
that.

At any rate, at this moment it's more of a specification issue than an
actual rakudobug.

Pm

From @coke

On Mon Jun 08 12​:02​:55 2015, pmichaud wrote​:

On Mon, Jun 08, 2015 at 06​:08​:33AM -0700, Will Coleda via RT wrote​:

I agree that this should be throwing the same conversion error.

I disagree to the extent that making min() throw the conversion error seems
to go against the purpose of designing soft/lazy Failure types into Perl 6
in the first place.

Sometimes we speak about not having the entire rocket explode simply
because of a few errors in the input set. In this case, min() is designed
to silently ignore undefined values in its calculations. Since in this
example all of the input values were undefined, min returned its 0-arg
case of Inf.

Perhaps an argument could be made that if min() is invoked on a list
consisting only of undefined values, it should return the first (undefined)
value instead of Inf. In other words, undefined values end up in this
middle-region between "lowest defined value" and "Inf", or something like
that.

At any rate, at this moment it's more of a specification issue than an
actual rakudobug.

Pm

Even if this was a Failure under the covers, in his example, he's say-ing the value, which should trigger the error at the point.
--
Will "Coke" Coleda

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

From @AlexDaniel

By the way, this was fixed. I'm not sure when, seems to be before 2015.10.

<AlexDaniel> m​: min(+'a', +'a').say
<camelia> rakudo-moar d1ebac​: OUTPUT«Cannot convert string to number​: base-10 number must begin with valid digits or '.' in '⏏a' (indicated by ⏏)␤ in block <unit> at <tmp> line 1␤␤Actually thrown at​:␤ in block <unit> at <tmp> line 1␤␤»

So it only needs tests.

From @zoffixznet

Tests added​: Raku/roast@683aeeaba8

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

From @salortiz

Seems to be agreement that the following two should be True, no?

  min(+'a') ~~ Failure
  min(+'a',+'a') ~~ Failure

From @AlexDaniel

Reopened per discussion on rakudo/rakudo#815 (comment)

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

From @zoffixznet

The decision has been reached and the referenced PR merged.

Tests unfudged in Raku/roast@78ccae4548

Re-closing.

--
Cheers,
ZZ | https://twitter.com/zoffix

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