[swift-evolution] Thoughts on clarity of Double and Float type names?
James Campbell
james at supmenow.com
Tue Jan 5 13:51:38 CST 2016
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?
Usually when mapped to Objective-C Swift values become NSIntegers anyways
which I don't believe is a pure float or double.
On Tue, Jan 5, 2016 at 7:20 PM, Goffredo Marocchi via swift-evolution <
swift-evolution at swift.org> wrote:
> 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.
>
>
> 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.
>
> Sent from my iPhone
>
> On 5 Jan 2016, at 18:40, Chris Lattner via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> 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):
>
> 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.
>
> 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*:
>
> 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?
>
> 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
>
> _______________________________________________
> 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
>
>
--
Wizard
james at supmenow.com
+44 7523 279 698
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160105/78e42583/attachment.html>
More information about the swift-evolution
mailing list