Make sub version of min/max/minmax on Ranges consistent

[lizmat]

with the method equivalent. Since "min" and "max" are attributes on the Range object, they will always reflect the "left" and "right" values in the Range (even for Ranges such as (10..-10).

There were no sub versions of min/max/minmax for Ranges, so they followed Iterable logic. Which would give different results from the method version. And rather unexpected ones as well:

say max 10..-10;  # -Inf, because (10..-10).list is an empty List
say max ^3;       # 2, because (^3).list is (0,1,2)

[lizmat]

Inspired by discussion at https://irclogs.raku.org/raku-beginner/2023-06-29.html#17:18

[librasteve]

Reflecting a IRC chat conversation here:

https://discord.com/channels/538407879980482560/768511641758466088/1124306059352350760

librasteve: Range method minmax seems to have the situation right and could be generalised to the min and max operations [according to the docs https://docs.raku.org/type/Range#method_minmax] -->

librasteve: If the Range is an integer range (as indicated by is-int), then this method returns a list with the first and last value it will iterate over (taking into account excludes-min and excludes-max). If the range is not an integer range, the method will return a two element list containing the start and end point of the range unless either of excludes-min or excludes-max are True in which case a Failure is returned.

[note that minmax is distinct from bounds in that bounds always simply returns the specified range bounds and ignores exclusions]

librasteve: So I would say that the right thing is to make min and max follow the same logic as minmax

[...]

Raku bridge: which is what #5300 does, right ?

[17:31]librasteve: nope
[17:31]librasteve: m: say minmax (2..^9) Raku eval: (2 8)
[17:32]librasteve: m: say max (2..^9) Raku eval: 8
[17:32]librasteve: m: say minmax (2..^9.3) Raku eval: (2 9)
[17:33]librasteve: m: say (2..^9.3).minmax Raku eval: Exit code: 1
Cannot return minmax on Range with excluded ends
in block at main.raku line 1
[17:34]librasteve: weird, the sub version of minmax ought to fail
[17:34]librasteve: m: say max (2..^9.3) Raku eval: 9
[17:35]librasteve: m: say (2..^9.3).max Raku eval: 9.3

Sooo, I think that the individual min and max operators should follow the minmax logic in that
(i) they return the inner value for excluded bounds if is-int
(ii) they fail if they hit an excluded bound and ! is-int

And, obviously (?), the sub and method form should do the same.

[lizmat]

And, obviously (?), the sub and method form should do the same.

That's what this PR does, at least. Now, as to changing the semantics, that's going to be another issue, I'd say. And something that would probably need a language level bump.

[librasteve]

yeah - potentially a breaking change ... certainly this PR is a step forward and I do not wish to stop it