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

[Stephen Canon]

What would this actually gain, other than most floating-point code producing different results even for basic arithmetic when run on differing platforms?  Having “Int” mean “native word size” is tolerable because:

(a) most integer code deals with small numbers for which the result is the same either way
(b) if the result were different due to overflow, that would trap in Swift

Neither of these properties holds for floating-point.  1/3 will give one result on one platform, and another result on another platform.  Floating-point has enough misunderstood sharp edges as is.  We don’t need to add more.

– Steve

> On Jan 5, 2016, at 4:10 PM, Paul Cantrell via swift-evolution <swift-evolution at swift.org> wrote:
> 
> In principle, having Float, Float32, and Float64 and no “Double” at all seems highly sensible to me.
> 
> In practice, the migration cost of changing the meaning of Float from “32-bit” to “platform preferred size” seems like a potential deal-killer.
> 
> P
> 
>> On Jan 5, 2016, at 2:25 PM, Alex Johnson via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> Just to clarify: I was suggesting removing the name "Double" and giving a different meaning to the name "Float".
>> 
>> ~ Alex
>> 
>> On Tue, Jan 5, 2016 at 11:51 AM, Chris Lattner <clattner at apple.com <mailto:clattner at apple.com>> wrote:
>> 
>> 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.
>>  _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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