<div dir="ltr">Is there a reason we need a Double as well as a Float ? I see the value in Int and Float butt could they not both be the biggest value supported on the platform?<div><br></div><div><br></div><div>Usually when mapped to Objective-C Swift values become NSIntegers anyways which I don&#39;t believe is a pure float or double.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 5, 2016 at 7:20 PM, Goffredo Marocchi 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"><span class=""><div><blockquote type="cite"><font color="#000000"><span style="background-color:rgba(255,255,255,0)">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&quot; 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><br></div></span><div>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><br>Sent from my iPhone</div><div><div class="h5"><div><br>On 5 Jan 2016, at 18:40, Chris Lattner 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>On Jan 4, 2016, at 12: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><blockquote type="cite"><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”.</div></div></blockquote><div><br></div><blockquote type="cite"><div><div dir="ltr"><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></div></div></blockquote><div><br></div><div>Yes, the proper IEEE names for these would be “Single” and “Double”.  We briefly considered and rejected that.</div><div><br></div><blockquote type="cite"><div><div dir="ltr"><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></ol></div></div></div></div></blockquote><div>Yes, I think that 64-bit Float would be *actively* confusing to people, and using that name could cause real harm.</div><div><br></div><blockquote type="cite"><div><div dir="ltr"><div><div>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></div></div></div></div></blockquote><div>Aside from #3 (CGFloat is a distinct type in Swift, not an alias) and #5 :-)  I agree with these points.</div><div><br></div><div>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&quot; 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.</div><div><br></div><div>-Chris</div><div><br></div></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=dXNHRXbGTqqssqDI7Hn7KyogJzdRthQdFNkQ7LxhQVP-2FlYXTBguQwvlh4mw52MbPC6vb754J642cH5nlNVJO07UGPOkF1zG110zL8iIwrF4z3kMLPumW0FaxPkOfWlH8f7lJgWAZT0nc3wuKqGArh5mXfaE7OqBsGnE1SNaGotVjvYKpPldxa5mxf9Mk-2B1JH7ipyGL83pcG3KUBm1s0FXYcNbwXL0hSCzrvLEGKEVoA-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">

</div></blockquote></div></div><blockquote type="cite"><div><span>_______________________________________________</span><span class=""><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></span></div></blockquote>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=xV0JY-2FdZMnUMvSFtZnLiBPRTDDOSQf3-2FpH33HYOlBxHw73DNC-2FNyYYpai77WftiWcjtbxqU7SyTN85iXxSpkAo2AWbT2KAUYHSMLSGqlTX8q2-2BScMsImPfcwECP8hUBw4v4FYvgD7G73WLLbVxzUAed01B6RX27MczrxlzSA2HF9QXw-2FJ-2FeVz6N-2BmCKITCaKTHxU97t8WAhphKSarZAGVm2knS8mhOLq2sbGIhnpqIw-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">
</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><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div><span style="font-size:16px;line-height:19.2px"></span><span style="font-size:12.8px"> Wizard</span><br></div><div><a href="mailto:james@supmenow.com" target="_blank">james@supmenow.com</a></div><div>+44 7523 279 698</div></div></div></div></div></div>
</div>