<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><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. &nbsp;I don’t see any “active" problems with our current names. &nbsp;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. &nbsp;We are *omitting* a C feature by removing ++ and --. &nbsp;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. &nbsp;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. &nbsp;For things that could go either way, we should keep alignment with C.</div></div></div></blockquote><div><br class=""></div><div>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. &nbsp;I presume this is also the only reason Apple’s frameworks ever defined it.</div><div><br class=""></div><div>I would say, again from my experience, dropping Double and making Float track the machine size would be a valid thing to do. &nbsp;It would also provide a bit of synergy with the way Int is handled. &nbsp;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><br class=""></div><div>-kw</div></div></body></html>