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

[Jordan Rose]

> On Jan 5, 2016, at 13:22, Kevin Wooten 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.
>> 
>> These are functionally different cases.  We are *omitting* a C feature by removing ++ and --.  This proposal included keeping the name “Double” but giving it a different meaning.
>> 
>> There are good and bad parts of C syntax.  The goal is not to cargo cult all of the bad parts of C into Swift, it is to keep the good parts and discard the bad parts.  For things that could go either way, we should keep alignment with C.
> 
> All these points are sensible but from a standpoint of my real world experience we end up using a typealias for CGFloat in most scenarios because it does precisely what we want; that being it tracks natural size.  I presume this is also the only reason Apple’s frameworks ever defined it.
> 
> I would say, again from my experience, dropping Double and making Float track the machine size would be a valid thing to do.  It would also provide a bit of synergy with the way Int is handled.  Finally, as far as I know there is no “Long” or “LongLong” type in Swift, as there is in C/Java, so some precedent has been set to do this as well.

It's really not useful to have Float track the machine size. In pretty much all cases, you either care about precision or you care about memory usage. CPU word size is somewhat correlated with available RAM, but not so strongly.

Alex's original proposal was to make Float be Float64, always.

Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160105/6be386d4/attachment.html>