<div dir="ltr">Int is the same size as Int64 on a 64-bit machine but the same size as Int32 on a 32-bit machine. By contrast, modern 32-bit architectures have FPUs that handle 64-bit and even 80-bit floating point types. Therefore, it does not make sense for Float to be Float32 on a 32-bit machine, as would be the case in one interpretation of what it means to mirror naming &quot;conventions.&quot; However, if you interpret the convention to mean that Float should be the largest floating point type supported by the FPU, Float should actually be a typealias for Float80 even on some 32-bit machines. In neither interpretation does it mean that Float should simply be a typealias for what&#39;s now called Double.<div><br></div><div>Another issue to consider: a number like 42 is stored exactly regardless of whether you&#39;re using an Int32 or an Int64. However, a number like 1.1 is not stored exactly as a binary floating point type, and it&#39;s approximated *differently* as a Float than as a Double. Thus, it can be essential to consider what kind of floating point type you&#39;re using in scenarios even when the number is small, whereas the same is not true for integer types.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 23, 2016 at 7:48 PM, David Sweeris via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>I&#39;d prefer they mirror the integer type naming &quot;conventions&quot;, that is have an explicit &quot;Float32&quot; and &quot;Float64&quot; type, with &quot;Float&quot; being a typealias for Float64.<br><br>Sent from my iPhone</div><div><div class="h5"><div><br>On May 23, 2016, at 18:26, Adriano Ferreira via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br><br></div><blockquote type="cite"><div>Hi everyone,<br><br>Is there any draft/proposal related to this suggestion?<br><br>Best,<br><br>— A<div><br><div><blockquote type="cite"><div>On Jan 4, 2016, at 3:58 PM, Alex Johnson via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br><div><div dir="ltr"><div>Hi all,</div><div><br></div>I&#39;m curious how other members of the Swift community feel about the clarity of the &quot;Double&quot; and &quot;Float&quot; type names. It seems incongruous that the default type for integers is &quot;Int&quot;, but the default type for floating point numbers is not &quot;Float&quot;.<div><br></div><div>What if the name &quot;Float&quot; were given to the intrinsic, 64-bit floating point type? (And the existing &quot;Float&quot; and &quot;Double&quot; names were removed in favor of &quot;Float32&quot; and &quot;Float64&quot;?)</div><div><br></div><div><div><br></div><div><b>Discussion:</b></div><div><br></div><div>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><br></div><div>Here are some reasons to <b>keep Double and Float as they are</b> (numbered for easy reference, but otherwise unordered):<br></div><div><ol><li>&quot;Double&quot; and &quot;Float&quot; are more natural for developers who are &quot;familiar with C-like languages.&quot;</li><li>A corollary: A 64-bit &quot;Float&quot; type could be confusing to those developers.</li><li>Another corollary: Swift needs to interoperate with Objective C, and its &quot;float&quot; and &quot;double&quot; types.</li><li>Renaming these types would open the door to bike-shedding every type name and keyword in the language.<br></li><li>Changing the meaning of an existing type (&quot;Float&quot;) would be a bit PITA for existing code (although an automated migration from &quot;Float&quot; to &quot;Float32&quot; and &quot;Double&quot; to &quot;Float&quot; should be possible).</li><li>Renaming a fundamental type would take considerable effort.</li></ol>Here are some reasons to <b>rename these types</b>:</div><div><ol><li>The default for a &quot;float literal&quot; in Swift is a 64-bit value. It would feel natural if that that value were of type &quot;Float&quot;.</li><li>There are size-specific names for 32-bit (&quot;Float32&quot;) and 64-bit (&quot;Float64&quot;) floating point types. For cases where a size-specific type is needed, a size-specific name like &quot;Float32&quot; probably makes the intention of the code more clear (compared to just &quot;Float&quot;).</li><li>Apple&#39;s Objective C APIs generally use aliased types like &quot;CGFloat&quot; rather than raw float or double types.</li><li>There is precedent for &quot;Float&quot; types being 64-bit in other languages like Ruby, Python and Go (as long as the hardware supports it).</li><li>What kind of a name for a type is &quot;Double&quot; anyways, amirite?<br></li></ol>(that last one is a joke, BTW)<br></div><div><div><br></div><div>What do you think? Do you agree or disagree with any of my assessments? Are there any pros or cons that I&#39;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><br></div><div>Thanks for your time and attention,</div><div>Alex Johnson (@nonsensery)<br></div></div></div></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=Q0Y0L54uOhrrHtFzGFlMm3oC4gejexfeaix2NKEDTe521-2BOYr8EXHzsXC5KMN1I-2BqToKhRy3DV5qg4zrFhFats37PqMsc0OSqEIUZcdOShf5p706RskqG3k-2BBvLQZStocn2GXm01A6Ogef4I-2BKR-2FbIxSf6dxAWsE3B4aAl6tpIRwNBNn5jQ49YcRsSmQ0qqZl5nLlw3xZqO9HNYs8cKMjHS7RyZTp4uSgJ7Biw5h4LM-3D" alt="" width="1" height="1" border="0" style="min-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">
_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br></div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></div></div><br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div></div>