<div dir="ltr">Thinking a little more about this how about just adding failable constructors so it becomes easier to deal with runtime narrowing errors for those that need it? (that was my main issue I ran across when using these classes in an early project, I had to put code around things to deal with the edge case that the library was already obviously doing)<div><br></div><div><span><div>extension UInt16 {</div><div>    public init(_ v: UInt8)</div><div>    public init(_ v: Int8)</div><div>    public init(_ v: Int16)</div><div>    public init(_ v: UInt32)                    // runtime narrowing check, asserts BOOOM</div><div>    public init?(validatingValue: UInt32)       // runtime narrowing check, failable initializer</div><div>    public init(truncatingBitPattern: UInt32)   // narrowing &quot;fixup&quot; initializer</div><div>    public init(_ v: Int32)                     // runtime narrowing check, asserts BOOOM</div><div>    public init?(validatingValue: UInt32)       // runtime narrowing check, failable initializer</div><div>    public init(truncatingBitPattern: Int32)    // narrowing &quot;fixup&quot; initializer</div><div> ...</div><div>    public init(bitPattern: Int16)              // I know what I doing! (aka live dangerously)</div><div>}</div></span></div><div><br></div><div>Ideally – to me – you would want the failable initializers to be the default ones available with the boom crash ones being something you could switch to use much like the the other special &quot;i know what I am doing ones&quot;. Not sure of the naming to use for such an initializer however.<br><div><br></div><div><span><span>-Shawn</span></span></div></div><div dir="ltr"><div><div><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Feb 16, 2016 at 11:28 AM Shawn Erickson &lt;<a href="mailto:shawnce@gmail.com" target="_blank">shawnce@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>It makes you think about this very real pitfall (in some problem domains) when going between numerical types.<br><div><br></div><div>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.</div></div></div><div dir="ltr"><div><div><br><div><br></div><div>-Shawn</div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Feb 16, 2016 at 11:11 AM David Turnbull &lt;<a href="mailto:dturnbull@gmail.com" target="_blank">dturnbull@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Can you show some examples where and why you use not-Int types and this is a problem? What you&#39;re suggesting will be a burden to those of us who need bitwise optimizations or work with C APIs.<div><br></div><div>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 &quot;<span style="font-size:13px">truncatingBitPattern&quot; taking up 25% of an 80 column line).</span></div><div><span style="font-size:13px"><br></span></div><div>So my question is, &quot;why are you not using Int?&quot; There&#39;s plenty of use cases, you just haven&#39;t stated yours so we can&#39;t understand why the current system is failing you.</div></div><div dir="ltr"><div><span style="font-size:13px"><br></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:13px">Safety does not mean you can easily write code that crashes once it is deployed….</span></blockquote><div><span style="font-size:13px"><br></span></div></div><div dir="ltr"><div>var a = [Int](); a[0]=99</div><div><br></div><div>That was pretty easy. I don&#39;t buy into this argument. If you don&#39;t want an out of bounds error, you either make sure you don&#39;t math your way out of bounds or you check every time before you subscript. I don&#39;t see why an integer conversion should be any different.</div></div><div dir="ltr"><div><br></div><div>-david</div></div></blockquote></div></blockquote></div></div></div></div></div>