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