[swift-evolution] Thoughts on clarity of Double and Float type names?

Chris Lattner clattner at apple.com
Tue Jan 5 12:40:04 CST 2016


On Jan 4, 2016, at 12:58 PM, Alex Johnson via swift-evolution <swift-evolution at swift.org> wrote:
> Hi all,
> 
> 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”.

> Discussion:
> 
> 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.

Yes, the proper IEEE names for these would be “Single” and “Double”.  We briefly considered and rejected that.

> Here are some reasons to keep Double and Float as they are (numbered for easy reference, but otherwise unordered):
> "Double" and "Float" are more natural for developers who are "familiar with C-like languages."
> A corollary: A 64-bit "Float" type could be confusing to those developers.
Yes, I think that 64-bit Float would be *actively* confusing to people, and using that name could cause real harm.

> Here are some reasons to rename these types:
> 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".
> 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").
> Apple's Objective C APIs generally use aliased types like "CGFloat" rather than raw float or double types.
> There is precedent for "Float" types being 64-bit in other languages like Ruby, Python and Go (as long as the hardware supports it).
> What kind of a name for a type is "Double" anyways, amirite?
Aside from #3 (CGFloat is a distinct type in Swift, not an alias) and #5 :-)  I agree with these points.

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.

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160105/703d0a1f/attachment.html>


More information about the swift-evolution mailing list