<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I launched a similar thread just a few days ago. <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160208/009950.html" class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160208/009950.html</a><br class=""><div class="">
<br class="Apple-interchange-newline"><span style="color: rgb(0, 0, 0); font-family: 'Lucida Grande'; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline !important; float: none;" class="">Félix</span>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">Le 16 févr. 2016 à 15:37:17, Shawn Erickson via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Ok one last reply to myself...<div class=""><br class=""></div><div class=""><span class=""><div class="">public class Int16 {</div><div class=""> public init(_ v: UInt8) {}</div><div class=""> public init(_ v: Int8) {}</div><div class=""> </div><div class=""> public init?(_ v: UInt16) {...on overflow return nil...}</div><div class=""> public init(assertValue: UInt16) {...on overflow assert...} // I think we could just drop this</div><div class=""> public init(truncatingValue: UInt16) {...on overflow truncate, alway positive...}</div><div class=""> </div><div class=""> public init?(_ v: Int32) {...on overflow return nil...}</div><div class=""> public init(assertValue: Int32) {...on overflow assert...} // I think we could just drop this</div><div class=""> public init(truncatingValue: Int32) {...on overflow truncate, maintain sign...}</div><div class=""> </div><div class=""> public init?(_ v: UInt32) {...on overflow return nil...}</div><div class=""> public init(assertValue: UInt32) {...on overflow assert...} // I think we could just drop this</div><div class=""> public init(truncatingValue: UInt32) {...on overflow truncate, alway positive...}</div><div class=""> </div><div class=""> ...others...</div><div class=""> </div><div class=""> public init(bitPattern: UInt16) {...close your eyes and copy the bits...}</div><div class="">}</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">let unsigned32 = UInt32(UInt16.max + 50)</div><div class=""><br class=""></div><div class="">guard let foo = Int16(unsigned32) else {</div><div class=""> throw Blah ...or... assert("BOOM")</div><div class="">}</div><div class="">...do stuff...</div><div class=""><br class=""></div><div class="">...or...</div><div class=""><br class=""></div><div class="">if let foo = Int16(unsigned32) {</div><div class=""> ...do stuff...</div><div class="">}</div><div class="">else {</div><div class=""> ...handle error...</div><div class="">}</div><div class=""><br class=""></div><div class="">...or...</div><div class=""><br class=""></div><div class="">let foo = Int16(truncatingValue: unsigned32)</div><div class="">...do stuff...</div><div class=""><br class=""></div><div class="">...or...</div><div class=""><br class=""></div><div class="">let foo = Int16(assertValue: unsigned32) //again I think we could just drop this</div><div class="">...do stuff unless I just went boom...</div></span><br class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Tue, Feb 16, 2016 at 11:57 AM Shawn Erickson <<a href="mailto:shawnce@gmail.com" class="">shawnce@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">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 class=""><br class=""></div><div class=""><span class=""><div class="">extension UInt16 {</div><div class=""> public init(_ v: UInt8)</div><div class=""> public init(_ v: Int8)</div><div class=""> public init(_ v: Int16)</div><div class=""> public init(_ v: UInt32) // runtime narrowing check, asserts BOOOM</div><div class=""> public init?(validatingValue: UInt32) // runtime narrowing check, failable initializer</div><div class=""> public init(truncatingBitPattern: UInt32) // narrowing "fixup" initializer</div><div class=""> public init(_ v: Int32) // runtime narrowing check, asserts BOOOM</div><div class=""> public init?(validatingValue: UInt32) // runtime narrowing check, failable initializer</div><div class=""> public init(truncatingBitPattern: Int32) // narrowing "fixup" initializer</div><div class=""> ...</div><div class=""> public init(bitPattern: Int16) // I know what I doing! (aka live dangerously)</div><div class="">}</div></span></div><div class=""><br class=""></div><div class="">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 "i know what I am doing ones". Not sure of the naming to use for such an initializer however.</div></div><div dir="ltr" class=""><div class=""><br class=""><div class=""><br class=""></div><div class=""><span class=""><span class="">-Shawn</span></span></div></div></div><div dir="ltr" class=""><div dir="ltr" class=""><div class=""><div class=""><br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Tue, Feb 16, 2016 at 11:28 AM Shawn Erickson <<a href="mailto:shawnce@gmail.com" target="_blank" class="">shawnce@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">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 class=""><br class=""></div><div class="">It makes you think about this very real pitfall (in some problem domains) when going between numerical types.<br class=""><div class=""><br class=""></div><div class="">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" class=""><div class=""><div class=""><br class=""><div class=""><br class=""></div><div class="">-Shawn</div></div></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Tue, Feb 16, 2016 at 11:11 AM David Turnbull <<a href="mailto:dturnbull@gmail.com" target="_blank" class="">dturnbull@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">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.<div class=""><br class=""></div><div class="">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 "<span style="font-size:13px" class="">truncatingBitPattern" taking up 25% of an 80 column line).</span></div><div class=""><span style="font-size:13px" class=""><br class=""></span></div><div class="">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.</div></div><div dir="ltr" class=""><div class=""><span style="font-size:13px" class=""><br class=""></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" class="">Safety does not mean you can easily write code that crashes once it is deployed….</span></blockquote><div class=""><span style="font-size:13px" class=""><br class=""></span></div></div><div dir="ltr" class=""><div class="">var a = [Int](); a[0]=99</div><div class=""><br class=""></div><div class="">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.</div></div><div dir="ltr" class=""><div class=""><br class=""></div><div class="">-david</div></div></blockquote></div></blockquote></div></div></div></div></div></blockquote></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>