Saline: Saturating Arithmetic in Crystal

[RespiteSage]

@jhass

For the readme example, how about something like…

This is a good point. I’ll update the README. In particular, my number choice seems to have caused confusion already…

@jhass

I’m not sure why you’d want to keep multiple implementation around, the intrinsics version should beat them all :)

I don’t like throwing stuff away… However, if I’m able to keep an API that’s easy to use (like, I’d argue, the current one), I’m fine only using the LLVM-based implementation.

@bcardiff

@kinxer using begin/rescue to recover from exception will probably be slow … [use LLVM intrinsics]

Yeah, that’s on my to-do list. I saw your code snippet, and I was planning on using something like that. However, I think wrapping it in a type will probably still be a friendlier API.

OT

@IEatReturnValues4

Pick one.

I had worked on saturating arithmetic a little before, but a large part of the reason I made this shard was so that you could use it. I’m not asking for overflowing gratitude, but it would be nice if you weren’t rude about this thing that was made for you.

@IEatReturnValues4

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 .

This is a product of my bad example in the README (see @jhass’s post above). In a call Saturating(T).new(x), the T is obviously the type, and the x is the value you want the variable to have (not the max). I’ll be changing the README to make that more clear.

@IEatReturnValues4

Would be better and more bonus points if we could simply do Saturating.new(0_u32) …

I don’t think this is possible, but I’ll look into it.

@IEatReturnValues4

There underlies the problem …

People have discussed this with you, and I’m not going to rehash this argument. This thread is not a place to argue that this shard shouldn’t exist because you think the language should already work like this.