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 < [email protected]> 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 < > [email protected]> wrote: > > 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): > > 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > -- Wizard [email protected] +44 7523 279 698
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
