Crystal: Make IO#write and others return the written byte count

[bcardiff]

This will allow accounting for the current position in the IO without calling IO#pos.

The return type should probably by UInt64 as in #7660

This is usually the case in other languages.

• Ruby https://ruby-doc.org/core-2.5.1/IO.html#method-c-write
• Go https://golang.org/pkg/io/#WriteString
• Rust https://doc.rust-lang.org/std/io/trait.Write.html

[asterite]

Could we make it Int64? Same in other places? In Go it returns int. We should try avoiding using unsigned integers.

[asterite]

Typed too fast. Maybe now that we have overflow and underflow, unsigned integers are not dangerous anymore.

[bcardiff]

@asterite you were worried about Int64 + UInt64 operations?

[asterite]

something like:

written_bytes = io.write(...)
if written_bytes - 10 < 20
end

If we use UInt64 then written_bytes - 10 can underflow, but with Int64 it will work fine in %99.999 of the cases.

The reason is always the same: unsigned integers are not obvious.

[bcardiff]

I see. I have no strong opinions regarding if it should be Int64 or UInt64. Both seems fine to me.

[asterite]

Yeah, either is probably fine. My comment is just "this will probably bit someone" so we should take that into account when choosing a type.

[RX14]

I'd prefer to keep UInt64 standard for "large" sizes.

[straight-shoota]

I doubt whether there's a realistic use case for processing anything close to 8 exabytes of data. And if such amounts of data would be reasonable, it probably wouldn't help much to double that with UIn64.
We could certainly add methods that return the raw unsigned integer value. But I'd rather prefer the safer signed type for most typical applications.

[bcardiff]

Since OffT is signed and is used as return type on system_pos (and IO#pos) for consistency we can stick with signed.

C api return signed but probably just to return -1 as error code.

Since it's a positive amount what it represents and errors will raise exceptions, using unsigned should be enough and accurate.

Both signed and unsigned are equally safe. The issue is what should be more comfortable to the user; without cutting feasible scenarios.

[asterite]

Both signed and unsigned are equally safe

I don't think this is true. As I showed, if you subtract an amount from an unsigned value, if it's less than that value it will underflow. You will only notice this happens depending on the amount written, so it's not a bug you will detect early. The problem doesn't exist with signed values (or it's much, much less likely to happen).

[bcardiff]

I think that that fall in the comfortable aspects and not in the safety one. If you are computing negative numbers as a result of the position there is probably something already wrong. I'm not saying that unsigned should be preferred over signed.

[RX14]

The main good reason for returning U64 is not having to change the return value of IO.copy. I don't really mind but sticking to one or the other 64 bit type consistently is a good idea.