[swift-evolution] Warning for possible overflow or optional

[Shawn Erickson]

I believe you stated that you ran across at least two times that runtime
checks caught a narrowing error (e.g. overflow) in your recent work. I
support runtime checks however I feel in the case of operations that could
have a narrowing issue using a failable constructor makes sense. It puts
you control in how to deal with a narrowing error. You could assert if you
so want (much like what happens now) or you could deal with the edge case.
Swift makes the code to deal with a failable  initializer generally trivial.

It makes you think about this very real pitfall (in some problem
domains) when going between numerical types.

The issue of why are you using unsigned, etc. is orthogonal to this issue.
If these types exist in the language folks will use them and it should be
safe / consistent for them when they do.

-Shawn

On Tue, Feb 16, 2016 at 11:11 AM David Turnbull <dturnbull at gmail.com> wrote:

> Can you show some examples where and why you use not-Int types and this is
> a problem? What you're suggesting will be a burden to those of us who need
> bitwise optimizations or work with C APIs.
>
> My last week was spent reading files with huffman coding. So I had no
> choice but to use bitwise operations. My experience is that Swift got this
> right (except for "truncatingBitPattern" taking up 25% of an 80 column
> line).
>
> So my question is, "why are you not using Int?" There's plenty of use
> cases, you just haven't stated yours so we can't understand why the current
> system is failing you.
>
> Safety does not mean you can easily write code that crashes once it is
>> deployed….
>
>
> var a = [Int](); a[0]=99
>
> That was pretty easy. I don't buy into this argument. If you don't want an
> out of bounds error, you either make sure you don't math your way out of
> bounds or you check every time before you subscript. I don't see why an
> integer conversion should be any different.
>
> -david
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160216/2449514f/attachment.html>