<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">+1. I think it brings a nice symmetry with the integer types and puts size classing in a more consistent place.<div class=""><br class=""></div><div class="">And to be frank, I already typedef the intrinsic float/double types in my C code to f32/f64 for similar reasons.<br class=""><div class=""><br class=""></div><div class="">-David<br class=""><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 4, 2016, at 12:58 PM, Alex Johnson 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=""><div dir="ltr" class=""><div class="">Hi all,</div><div class=""><br class=""></div>I'm curious how other members of the Swift community feel about the clarity of the "Double" and "Float" type names. It seems incongruous that the default type for integers is "Int", but the default type for floating point numbers is not "Float".<div class=""><br class=""></div><div class="">What if the name "Float" were given to the intrinsic, 64-bit floating point type? (And the existing "Float" and "Double" names were removed in favor of "Float32" and "Float64"?)</div><div class=""><br class=""></div><div class=""><div class=""><br class=""></div><div class=""><b class="">Discussion:</b></div><div class=""><br class=""></div><div class="">I understand the origins of these names in single- and double-precision IEEE floats. But this distinction feels like a holdover from C (and a 32-bit world), rather than a natural fit for Swift.</div><div class=""><br class=""></div><div class="">Here are some reasons to <b class="">keep Double and Float as they are</b> (numbered for easy reference, but otherwise unordered):<br class=""></div><div class=""><ol class=""><li class="">"Double" and "Float" are more natural for developers who are "familiar with C-like languages."</li><li class="">A corollary: A 64-bit "Float" type could be confusing to those developers.</li><li class="">Another corollary: Swift needs to interoperate with Objective C, and its "float" and "double" types.</li><li class="">Renaming these types would open the door to bike-shedding every type name and keyword in the language.<br class=""></li><li class="">Changing the meaning of an existing type ("Float") would be a bit PITA for existing code (although an automated migration from "Float" to "Float32" and "Double" to "Float" should be possible).</li><li class="">Renaming a fundamental type would take considerable effort.</li></ol>Here are some reasons to <b class="">rename these types</b>:</div><div class=""><ol class=""><li class="">The default for a "float literal" in Swift is a 64-bit value. It would feel natural if that that value were of type "Float".</li><li class="">There are size-specific names for 32-bit ("Float32") and 64-bit ("Float64") floating point types. For cases where a size-specific type is needed, a size-specific name like "Float32" probably makes the intention of the code more clear (compared to just "Float").</li><li class="">Apple's Objective C APIs generally use aliased types like "CGFloat" rather than raw float or double types.</li><li class="">There is precedent for "Float" types being 64-bit in other languages like Ruby, Python and Go (as long as the hardware supports it).</li><li class="">What kind of a name for a type is "Double" anyways, amirite?<br class=""></li></ol>(that last one is a joke, BTW)<br class=""></div><div class=""><div class=""><br class=""></div><div class="">What do you think? Do you agree or disagree with any of my assessments? Are there any pros or cons that I've missed? Is the level of effort so large that it makes this change impractical? Is it a colossal waste of human effort to even consider a change like this?</div><div class=""><br class=""></div><div class="">Thanks for your time and attention,</div><div class="">Alex Johnson (@nonsensery)<br class=""></div></div></div></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=nE9rxSXA5G4kxsTVkgv43pXkLx-2B36P-2BPNJufHeY0dgd6B91Zx6kw1bRgr7cj61-2F1yrUcMk5guKzIlz4bbNUVlNwGmDHrTvNiDXz64RHoAHx9-2FYm4lsk5qmjRp7ZUw3vZ0899SC0TGfZIRqLBDpYfbPf3OuBsDRy9VQYGpZLkq4mLFoxQ1J-2B1wPx7wI4ZN-2BjKl-2BUuyZqdmKj1gjSohkrjJQ-3D-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
_______________________________________________<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></div></div></body></html>