Open hutou opened 1 month ago
Quoting PR comments to bring the general discussion back here:
@straight-shoota https://github.com/crystal-lang/crystal/pull/14588#issuecomment-2107541871
Hm, actually this can overflow on ranges of
Int
types that are bigger thanInt32
🤔 Should we only cast toInt32
on smaller types?
@beta-ziliani https://github.com/crystal-lang/crystal/pull/14588#issuecomment-2130168028
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
).
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.
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?
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.
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)
@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.
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.
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 :shrug:
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.
The following snippet:
returns
instead of the expected