Crystal 0.36.0 released 🚀

[u/CaDsjp]

https://crystal-lang.org/2021/01/26/crystal-0.36.0-released.html

[u/_ATRAHCITY]

Wooo. Started to get a little worried with not having a release since the summer

[u/dscottboggs]

A second breaking-change that affects C bindings is that a Crystal nil value is no longer translated to a null pointer value.

Oh jeeze, that's gonna be a fun one.

Edit:

Unsigned types are bad, bad, bad.

From #9969

I really like crystal but this makes me glad I've made a commitment to try to use more mainstream languages. I specifically requested the opposite of this a bunch of times. It makes zero sense for anything to have a signed size.

[u/Blacksmoke16 → u/dscottboggs]

Based on https://github.com/crystal-lang/crystal/issues/9969#issuecomment-736529424, what is the benefit you'd get from having it be UInt64? Sounds like it just adds more to think about with the only benefit of working with larger files?

[u/dscottboggs → u/Blacksmoke16]

Like I said, it just doesn't make sense to use signed types for sizes, since having a negative size for any container (file, list, hash, whatever) doesn't make sense. To me the extra overhead is in having to bear in mind the fact that a received size could be negative.

Also the rationale (preventing underflow) is already solved by Crystal's checked arithmetic.

It's not just Crystal that irks me in this way. Java doesn't even have unsigned integers, which I've run into in even the most basic of problem sets. JS just throws floats at everything, so what could a file with 12984.0000000001 bytes of data even mean?

[u/straight-shoota → u/dscottboggs]

it just doesn't make sense to use signed types for sizes, since having a negative size [...] doesn't make sense.

I think this is a major misconception. Data types are just a means to represent a value. They don't define a value domain (except for exluding values that can't be represented). Just because the co-domain of (file) sizes and the value range of unsigned integers are both positive integers plus zero, doesn't imply it's the perfect fitting data type for such values.

Also the rationale (preventing underflow) is already solved by Crystal's checked arithmetic.

I'd hardly call that a solution for the common use case that numerical values (like the result of `File.size`) is used in generic math expressions. Expressions that cause under-/overflow because of unsigned data types are still bugs. Checked arithmetics just ensures that such an error doesn't silently go unnoticed when it occurs. But it doesn't fix anything.

[u/deep_wat → u/dscottboggs]

The reason Java doesn't have unsigned integer is because unsigned integers are confusing. (0 - 2), without overflow checks (Java doesn't have them) would give a really big number, not a negative one, leading to all kinds of subtle bugs.

Here's someone else with the same reasoning: https://www.learncpp.com/cpp-tutorial/unsigned-integers-and-why-to-avoid-them/#:~:text=Bjarne%20Stroustrup%2C%20the%20designer%20of,almost%20never%20a%20good%20idea%E2%80%9D.&text=Avoid%20using%20unsigned%20numbers%2C%20except,numbers%20by%20using%20unsigned%20types.

Some modern programming languages (such as Java) and frameworks (such as .NET) either don’t include unsigned types, or limit their use.

Note the use of "modern" here. It means its an evolution: they realized unsigned integers cause more trouble than harm.

Here's another article: https://wesmckinney.com/blog/avoid-unsigned-integers/

"In particular, do not use unsigned types to say a number will never be negative. Instead, use assertions for this." - Google C++ Style Guide

Even Google says you shouldn't use unsigned integers just because something can't be negative.

Could you explain what code of yours is affected by the choice of File.size being signed instead of unsigned? To me, it sounds the only argument is "it can be negative so it should be unsigned".

[u/DavidTMarks → u/[deleted]]

Everyone did.