<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 5, 2016, at 13:22, Kevin Wooten 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=""><div class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class=""><blockquote type="cite" class=""><font class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">That said, personally, my feeling is that the momentum here in the broad family of C languages (including things like Java) is very strong, and that diverging from that would be extremely problematic. I don’t see any “active" problems with our current names. If this is a matter of aesthetics, or an attempt to align with Ruby/Python/Go instead of C/Java etc, then this seems like the wrong direction for Swift.</span></font></blockquote></div><div class=""><br class=""></div><div class="">Losing alignment to C-like paradigms is a valid concern, but then removing unwary decrement and increment operators feels out of place... Sad to have seen it culled.<br class=""></div></div></div></blockquote></div><br class=""><div class="">These are functionally different cases. We are *omitting* a C feature by removing ++ and --. This proposal included keeping the name “Double” but giving it a different meaning.</div><div class=""><br class=""></div><div class="">There are good and bad parts of C syntax. The goal is not to cargo cult all of the bad parts of C into Swift, it is to keep the good parts and discard the bad parts. For things that could go either way, we should keep alignment with C.</div></div></div></blockquote><div class=""><br class=""></div><div class="">All these points are sensible but from a standpoint of my real world experience we end up using a typealias for CGFloat in most scenarios because it does precisely what we want; that being it tracks natural size. I presume this is also the only reason Apple’s frameworks ever defined it.</div><div class=""><br class=""></div><div class="">I would say, again from my experience, dropping Double and making Float track the machine size would be a valid thing to do. It would also provide a bit of synergy with the way Int is handled. Finally, as far as I know there is no “Long” or “LongLong” type in Swift, as there is in C/Java, so some precedent has been set to do this as well.</div></div></div></div></blockquote><br class=""></div><div>It's really not useful to have Float track the machine size. In pretty much all cases, you either care about precision or you care about memory usage. CPU word size is somewhat correlated with available RAM, but not so strongly.</div><div><br class=""></div><div>Alex's original proposal was to make Float be Float64, always.</div><div><br class=""></div><div>Jordan</div><br class=""></body></html>