> On Jan 5, 2016, at 13:22, Kevin Wooten 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. >> >> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
