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

Xiaodi Wu xiaodi.wu at gmail.com
Mon May 23 20:18:38 CDT 2016


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
"conventions." 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's now called Double.

Another issue to consider: a number like 42 is stored exactly regardless of
whether you'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's approximated
*differently* as a Float than as a Double. Thus, it can be essential to
consider what kind of floating point type you're using in scenarios even
when the number is small, whereas the same is not true for integer types.


On Mon, May 23, 2016 at 7:48 PM, David Sweeris via swift-evolution <
swift-evolution at swift.org> wrote:

> I'd prefer they mirror the integer type naming "conventions", that is have
> an explicit "Float32" and "Float64" type, with "Float" being a typealias
> for Float64.
>
> Sent from my iPhone
>
> On May 23, 2016, at 18:26, Adriano Ferreira via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Hi everyone,
>
> Is there any draft/proposal related to this suggestion?
>
> Best,
>
> — A
>
> On Jan 4, 2016, at 3: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".
>
> 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"?)
>
>
> *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.
>
> Here are some reasons to *keep Double and Float as they are* (numbered
> for easy reference, but otherwise unordered):
>
>    1. "Double" and "Float" are more natural for developers who are
>    "familiar with C-like languages."
>    2. A corollary: A 64-bit "Float" type could be confusing to those
>    developers.
>    3. Another corollary: Swift needs to interoperate with Objective C,
>    and its "float" and "double" types.
>    4. Renaming these types would open the door to bike-shedding every
>    type name and keyword in the language.
>    5. 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).
>    6. Renaming a fundamental type would take considerable effort.
>
> Here are some reasons to *rename these types*:
>
>    1. 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".
>    2. 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").
>    3. Apple's Objective C APIs generally use aliased types like "CGFloat"
>    rather than raw float or double types.
>    4. There is precedent for "Float" types being 64-bit in other
>    languages like Ruby, Python and Go (as long as the hardware supports it).
>    5. What kind of a name for a type is "Double" anyways, amirite?
>
> (that last one is a joke, BTW)
>
> 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?
>
> Thanks for your time and attention,
> Alex Johnson (@nonsensery)
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160523/83ced746/attachment.html>


More information about the swift-evolution mailing list