<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="">[Charlie, this is more of a reply to the thread than to your message in particular.]</div><div class=""><br class=""></div><div class="">There is absolutely no good reason to have a “word size” floating-point type. We happen to have one on Apple systems (CGFloat), but that should be viewed as a historical curiosity, not as guidance that it’s a reasonable thing to do. If we were starting from scratch today, we would not have such a type.</div><div class=""><br class=""></div><div class="">1. Having explicit `Float32`, `Float64`, [`Float16`, `Float128`, … ] type names, by analogy to integer types, is great.</div><div class=""><br class=""></div><div class="">2. Making `Float` and `Double` unavailable in favor of these replacements would be a lot of churn for relatively little value, but it’s not a bad idea if you ignore the one-time pain of conversion. `Float32` and `Float64` are discoverable enough that this would be OK, IMO.</div><div class=""><br class=""></div><div class="">3.a. Making `Float` a “word size” type is bonkers. The last thing we want to do is create another type with the same difficulties as `CGFloat`.</div><div class=""><br class=""></div><div class="">3.b. Making `Float` be “the widest HW-supported type” is less bonkers, but still results in gratuitous cross-platform differences and very little real benefit. We’d also need to be careful about how we defined it, since we would *not* want it to be `Float80` on x86_64 (for performance reasons).</div><div class=""><br class=""></div><div class="">3.c. Making `Float` be an alias of `Float64` would just confuse people coming from a C-family language (as commonly implemented).</div><div class=""><br class=""></div><div class="">– Steve</div><br class=""><div><blockquote type="cite" class=""><div class="">On May 24, 2016, at 12:52 AM, Charlie Monroe via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">In UIKit/Cocoa, there's CGFloat that does pretty much what you're asking (and it's pain working with it in Swift, since it's Double on 64-bit computers, while Swift defaults to Float, so you need casting all the time)... And I think the default behavior of Swift should be similar.<div class=""><br class=""></div><div class="">I wouldn't change the type names since Double still is "double precision", I'd just prefer changed default behavior...</div><div class=""><br class=""></div><div class="">Charlie<br class="">
<br class=""><div class=""><blockquote type="cite" class=""><div class="">On May 24, 2016, at 5:39 AM, David Sweeris via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On May 23, 2016, at 9:55 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote">On Mon, May 23, 2016 at 9:40 PM, David Sweeris<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:davesweeris@mac.com" target="_blank" class="">davesweeris@mac.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><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;"><br class=""></blockquote><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;">Have we (meaning the list in general, not you & me in particular) had this conversation before? This feels familiar...<br class=""></blockquote><div class=""><br class=""></div><div class="">It does, doesn't it? I've been reading this list for too long.</div></div></div></div></div></blockquote>I just checked, and we have! In this very thread! I didn’t realize it was started almost 6 months ago…</div><div class=""><br class=""></div><div class="">Out of curiosity, are there plans for Swift's IntegerLiteralType & FloatingPointLiteralType when CPUs eventually support 128-bit ints & floats? Will they still evaluate to “Int64" and “Double” by default, or will they become the bigger types?</div><div class=""><br class=""></div><div class="">- Dave Sweeris</div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></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=""></body></html>