> 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): >> "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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
