On Jan 4, 2016, at 12:58 PM, Alex Johnson via swift-evolution
<[email protected]> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
