I’m kinda just curious now. Is there ANY language that does what you’re suggesting?
@Blacksmoke16
No: c c++ c# go nim java ruby python perl?? crystal.
Maybe @IEatReturnValues4 can provide a list of languages that function the way he wants.
To be fair, what language has the simplicity of Fibers paired with sockets (TCPServer.new)? Not many. Just because other languages doesn’t have a particular feature or simplicity, doesn’t negate my opinion/view on exceptions on “arithmetic overflows”. Wouldn’t even be an overflow if it was set to the max value of you know, its type. Which is inferred when the developer explicitly sets an ivar to a type.
The fact that no other language does it should be enough to make you at least ask “why?”. You’ve been told, several times, why it’s a bad idea to do what you want. And it’s not like it’s even difficult behavior to emulate, you just want it to be your way from a language level, and that’s not going to happen.
Oh I already know how to fix it. Just simply use a one line if statement. I’m just saying, it’s redundant and totally unnecessary. Especially if you have a lot of int ivars
Except you’re wrong, as has been explained. If you have repeated behavior you can always write a simple iterator class that does what you want as well. Not a hard thing to do in Crystal.
Thanks, does that make you feel better?
You even suggesting to write an “iterator” class is such an over-engineering solution to this, it’s laughable.
This language is all about simplicity, not be littered with redundant code.
No, suggesting a breaking change of this magnitude to a language that’s almost stabilized in order to satisfy your one use case is laughable. Not listening to any of the advice you’ve been given, also laughable. Let’s be clear about one thing, simplicity does not equal stupidity.
A change like this would break a lot of existing code, just so you don’t have to write some if statements, a function, or an iterator class. That is laughable, and I recommend you go back and read some of the advice you were given rather than continuing to throw a tantrum.
1 Like
Yeah, because this is such a breaking change! I’d rather have my int values be set to their max value of their respective types, instead of my program crashing. That’s for sure.
You know you can catch exceptions, right? That’s what you should be doing if your number might overflow.
Yes, catch the “exception” instead of dealing with a maximum value the developer explicitly set to use!
Weeeeeeeeeeee!
Hey all, I’m closing this topic because it got a bit out of control.
There’s no denying saturating math is useful. However, making it a default will hide silent bugs. Before overflow errors we had wrapping math and it also caused silent bugs.
A shard or eventually the standard library could provide an API for saturating math. But again, it shouldn’t be the default.
10 Likes
Community spends hours arguing against an idea
Community member creates shard for said idea, gets a round of applause, “awesome work, man!”
Pick one.
Now, while this shard is good, the initializer parameter seems redundant. If it’s Saturating(Int32), it’s inferred we know the max value, we don’t need to pass in Int32::MAX. Likewise, for example, if it’s Saturating(UInt32), we know the max value as well.
Would be better and more bonus points if we could simply do Saturating.new(0_u32), or whatever inline type we specified.
This means that in any case when the wrapped type would overflow or underflow,
There underlies the problem. Intrinsically in crystal and how it’s infused with mathematics, there should be no underflows or overflows, when there is a MAX and MIN value paired with a respective Int type.
See image:
This reigns more true because of the Int32 (enum member variables).
When a developer is creating an instance var, let’s say property gold = 0. The developer knows the max value. If that developer wants to warn a user about reaching the max gold, that onus is on them. The onus is absolutely NOT on the developer to litter a codebase with redundant if statements. This goes against the entire point of having a beautiful syntax.
Other languages suffer from this as well (just tested it in dlang)
As mentioned in Arithmethic overflow should not raise an exception - #8 by bcardiff, the idea is good and has use cases. However, having this being the default behavior is what we were aruging against.
Ideally the implementation would be using LLVM like @bcardiff mentioned in Saline: Saturating Arithmetic in Crystal - #4 by bcardiff.
2 Likes
I think you’re misunderstanding what the initializer is for. It’s for the initial number value, which is kind of necessary when creating a number-like type unless you want to start at 0 every time which isn’t very practical.
1 Like
That min and max “number value” is already obtainable from the type.
We’re not talking about the min and max, but the value of the particular variable. For example, you might want the number 7. So if you wanted an Int32 you’d type Saturating(Int32).new(7).
Other languages are also Rust and Swift. Modern languages. These things weren’t done before. Maybe new languages are realizing that silent overflows are not a good thing after all?
The developer knows the max value
You know the max value. Developers probably know it too. However, they probably don’t think about whether said value can reach a maximum, and what should be done in that case. If it’s saturating, they will never know this happens and they will have a silent bug in their code. If it’s overflowing and getting to a negative value, or zero, it’s another bug that will manifest itself in very strange ways (things will start to work wrong and you’ll have no idea why). If it’s an exception, you immediately know where the problem is.
The exception is there to tell the developer “Hey, look, you reached the maximum value of this. Please consider what to do in this case”. In that case the developer can choose to use a bigger type so it’s less likely to overflow (maybe it will never overflow depending on the scenario), or maybe give the program user an error saying “You exceeded the maxium amount” or something like that.
I love videogames but they are not the only use case for Crystal.
2 Likes
I understand that I brought this upon myself somewhat for releasing this shard based on the closed thread from yesterday, but I don’t think that we need to continue to argue about the same thing on this thread until it is closed. While saturating arithmetic is relevant to this shard, changes to the standard library (or at least extensive discussion thereof) are off-topic in this thread.
3 Likes