Range#size returns an Union instead of an Int32

[hutou]

The following snippet:

range = 1_u8..5_u8
size = range.size
p! typeof(size)

returns

typeof(size) # => (Int32 | UInt8)

instead of the expected

typeof(size) # => Int32

[straight-shoota]

Quoting PR comments to bring the general discussion back here:

@straight-shoota #14588 (comment)

Hm, actually this can overflow on ranges of Int types that are bigger than Int32 🤔
Should we only cast to Int32 on smaller types?

@beta-ziliani #14588 (comment)

I'm afraid there's no good solution here. The good part of raising on overflow is that if it fits, it works. The bad part is that the failure is at runtime...

An alternative, as good or bad, is to statically fail on > Int32 types and have people do the math themselves 🤷

That's also not good because (0_u128..1_u128).size is perfectly valid 🤷

I think casting to Int32 is fine. If you use bigger number types, it will raise but that's ok. The implementation with - for Int types is just an optimization. The base implementation of Enumerable#size would iterate all the items and thus eventually overflow the counter if the difference is more than Int32 can handle.
The type of #size for all collection types is Int32 because it's meant for collections that can be feasibly represented in memory.

We'll eventually need to increase that size type in order to support bigger collections. But while Int64 should be entirely sufficient for the use case related to actual memory storage (e.g. Slice#size), Range#size is not materialized and can reach arbitrary scales (with BigInt etc.).

#size is simply not meant for this.

I think we should explain that caveat explicitly in the API docs and that's it. #size returns Int32 and if it doesn't fit, it will raise.

We should however consider adding an alternative method that unconditionally returns range.end - range.begin.
This would even be much more versatile because it would work not just with Int but any type that implements subtraction (e.g. 0_f32..1_f32, Time.utc..Time.utc).

[beta-ziliani]

We should however consider adding an alternative method that unconditionally returns range.end - range.begin.
This would even be much more versatile because it would work not just with Int but any type that implements subtraction (e.g. 0_f32..1_f32, Time.utc..Time.utc).

But how would this work if the range is exclusive?

I'm thinking that the only reason why the untyped #size method doesn't work is just because of the need to return the 0. Perhaps the real solution here is to use macros first to decide statically what to do with Int, and a method to cast an Int to another using the type. What I'm thinking is something like a Int#cast_to(Type), but it's not simple to implement. Then we can cast the 0 to the right type.

[straight-shoota]

Of course range.end - range.begin in general only works with an inclusive range. Perhaps we can have a special case for Int.

I don't follow what you mean in the rest of the comment about the type of 0 value. Why is that an issue?

[beta-ziliani]

If you do:

if bla
  0
else
  a - b
end

the result is the union of Int32 and whatever a and b are. This is why we get UInt8 | Int32. If we have a way to say "return 0, but casted to typeof(b)", then we drop the union and get the specific type.

[straight-shoota]

Okay, gotcha. But the problem is not the union alone. Returning anything but Int32 breaks the contract of Enumerable#size : Int32.

So there's no point in converging the return type on UInt8. It needs to be Int32.

(having 0 typed identically to the difference should be possible though with something like typeof(a - b).new(0); it just doesn't help anything)

[ysbaddaden]

@beta-ziliani We can do typeof(n).zero, but since we fallback to Enumerable#size for other cases then the returned type is still an union. We can use indeed use macros and the returned type will be typeof(B) (when B and E are integers):

{% if B < Int && E < Int %}
  ...
  n < 0 ? typeof(n).zero : n
{% else %}
  ...
{% end %}

The return type of Range(B, E)#size still won't match Enumerable#size, and it will be any integer type that B happens to be. At the very least it won't be an Union, and we could cast it to be at least an Int32.

I think range.begin - range.end is basically #14740.

[beta-ziliani]

ah yes, when I wrote this comment I was aware of the problem with the interface in Enumerable#size and now I forgot 🙈 Sorry for the noise.

[ysbaddaden]

TBH: I'm not sure which solution is best. I think both choices have pros and cons:
stable type but overflows vs unstable type but no overflow 🤷

[straight-shoota]

IMO there is no choice. The return type of any implementation of Enumerable#size must be Int32.
If we want a method to return anything else, it needs a different name.