Thoughts on clarity of Double and Float type names?

[Alex_Johnson]

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".

What if the name "Float" were given to the intrinsic, 64-bit floating point
type? (And the existing "Float" and "Double" names were removed in favor of
"Float32" and "Float64"?)

*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.

Here are some reasons to *keep Double and Float as they are* (numbered for
easy reference, but otherwise unordered):

   1. "Double" and "Float" are more natural for developers who are
   "familiar with C-like languages."
   2. A corollary: A 64-bit "Float" type could be confusing to those
   developers.
   3. Another corollary: Swift needs to interoperate with Objective C, and
   its "float" and "double" types.
   4. Renaming these types would open the door to bike-shedding every type
   name and keyword in the language.
   5. Changing the meaning of an existing type ("Float") would be a bit
   PITA for existing code (although an automated migration from "Float" to
   "Float32" and "Double" to "Float" should be possible).
   6. Renaming a fundamental type would take considerable effort.

Here are some reasons to *rename these types*:

   1. 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".
   2. 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").
   3. Apple's Objective C APIs generally use aliased types like "CGFloat"
   rather than raw float or double types.
   4. There is precedent for "Float" types being 64-bit in other languages
   like Ruby, Python and Go (as long as the hardware supports it).
   5. What kind of a name for a type is "Double" anyways, amirite?

(that last one is a joke, BTW)

What do you think? Do you agree or disagree with any of my assessments? Are
there any pros or cons that I've missed? Is the level of effort so large
that it makes this change impractical? Is it a colossal waste of human
effort to even consider a change like this?

Thanks for your time and attention,
Alex Johnson (@nonsensery)

[owensd (David Owens II)]

+1. I think it brings a nice symmetry with the integer types and puts size classing in a more consistent place.

And to be frank, I already typedef the intrinsic float/double types in my C code to f32/f64 for similar reasons.

-David

···

On Jan 4, 2016, at 12:58 PM, Alex Johnson via swift-evolution <swift-evolution@swift.org> 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".

What if the name "Float" were given to the intrinsic, 64-bit floating point type? (And the existing "Float" and "Double" names were removed in favor of "Float32" and "Float64"?)

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.

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.
Another corollary: Swift needs to interoperate with Objective C, and its "float" and "double" types.
Renaming these types would open the door to bike-shedding every type name and keyword in the language.
Changing the meaning of an existing type ("Float") would be a bit PITA for existing code (although an automated migration from "Float" to "Float32" and "Double" to "Float" should be possible).
Renaming a fundamental type would take considerable effort.
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?
(that last one is a joke, BTW)

What do you think? Do you agree or disagree with any of my assessments? Are there any pros or cons that I've missed? Is the level of effort so large that it makes this change impractical? Is it a colossal waste of human effort to even consider a change like this?

Thanks for your time and attention,
Alex Johnson (@nonsensery)
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Chris_Lattner]

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

···

On Jan 4, 2016, at 12:58 PM, Alex Johnson via swift-evolution <swift-evolution@swift.org> wrote:

[Janosch_Hildebrand]

I also think that Float and Double are not ideal type names but I also agree with many of the concerns that have been raised.

Why not simply use (the existing) Float32 and Float64 while keeping everything else equal?

So as a first step we could encourage the use of Float32/Float64 over Float/Double:
Make Float/Double typealiases for Float32/Float64 instead of the reverse which is true today
Use Float32/Float64 in documentation and example code
Perhaps add a note to the documentation for Float/Double that the Float32/Float64 types should be preferred
...

This would not break any existing code and I think would be a positive change in the long term.
Also this might have a better chance to be accepted as a proposal and by the community at large.

Making Float32/Float64 the officially preferred types should still help their adoption a lot without the pains involved in removing Float/Double.

And the deprecation and eventual removal of Float/Double could still be considered separately either now or down the road if people actually adopt Float32/Float64. Also migration would be very simple in this case (and stragglers could simply create their own Float/Double typealiases).

- Janosch

[David_Sweeris]

My thoughts are that I wish they’d been named Float32 and Float64, and that “Float” was typealiased to the “native word size” floating point type, so that all the numeric types had the same naming scheme. But with Float/Double being around for, what, 1.5(?) years, I wouldn’t blame anyone for thinking it’s not worth the hassle to switch (although I would be in favor of it if there was an actual vote or something).

Also, it’d be nice to have built-in arbitrary precision types for us math nerds, but I’m well aware that’s a whole other thing.

···

On Jan 4, 2016, at 12:58, Alex Johnson via swift-evolution <swift-evolution@swift.org> 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".

[Adriano_Ferreira]

Hi everyone,

Is there any draft/proposal related to this suggestion?

Best,

— A

···

On Jan 4, 2016, at 3:58 PM, Alex Johnson via swift-evolution <swift-evolution@swift.org> 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".

What if the name "Float" were given to the intrinsic, 64-bit floating point type? (And the existing "Float" and "Double" names were removed in favor of "Float32" and "Float64"?)

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.

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.
Another corollary: Swift needs to interoperate with Objective C, and its "float" and "double" types.
Renaming these types would open the door to bike-shedding every type name and keyword in the language.
Changing the meaning of an existing type ("Float") would be a bit PITA for existing code (although an automated migration from "Float" to "Float32" and "Double" to "Float" should be possible).
Renaming a fundamental type would take considerable effort.
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?
(that last one is a joke, BTW)

What do you think? Do you agree or disagree with any of my assessments? Are there any pros or cons that I've missed? Is the level of effort so large that it makes this change impractical? Is it a colossal waste of human effort to even consider a change like this?

Thanks for your time and attention,
Alex Johnson (@nonsensery)
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Chris_Lattner]

What perceived problem are you solving?

-Chris

···

On Jan 5, 2016, at 4:41 PM, Janosch Hildebrand via swift-evolution <swift-evolution@swift.org> wrote:

I also think that Float and Double are not ideal type names but I also agree with many of the concerns that have been raised.

Why not simply use (the existing) Float32 and Float64 while keeping everything else equal?

[Panajev (Goffredo Marocchi)]

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 <swift-evolution@swift.org> wrote:

On Jan 4, 2016, at 12:58 PM, Alex Johnson via swift-evolution <swift-evolution@swift.org> 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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Panajev (Goffredo Marocchi)]

Hello Chris,

When dealing with floating point values, wouldn't it be in our best interest to always be very specific about the accuracy of the floating point type variables we use regardless of the device it runs on? This is the biggest problem I had with CGFloat: while it is nice at first to have a type that adapts to the device word size it runs on, I prefer to always have an explicit accuracy guarantee than worrying about my CGFloat code changing in behaviour when it runs on a 32 bit device rather than a 64 bit one.

···

Sent from my iPhone

On 6 Jan 2016, at 02:08, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On Jan 5, 2016, at 4:41 PM, Janosch Hildebrand via swift-evolution <swift-evolution@swift.org> wrote:

I also think that Float and Double are not ideal type names but I also agree with many of the concerns that have been raised.

Why not simply use (the existing) Float32 and Float64 while keeping everything else equal?

What perceived problem are you solving?

-Chris

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Brent_Royal-Gordon]

What perceived problem are you solving?

Here are the problems I see it solving:

- **Swift makes no recommendations about which floating-point type to use.** Integer types have a clear recommendation: use Int unless you have a compelling reason to use something else. Which float type should you use? Swift just kind of shrugs. This is especially ugly because Swift is so strict about mixing numeric types; by making no recommendation, Swift encourages people to create systems with inconsistent numeric types that require more conversions. And conversions are especially dangerous in floating-point types which are by their nature imprecise.

- **`Double` is a meaningless name unless you come from a C-style background.** This is particularly true for learners. With `Float`, you can at least explain that the type name is short for "floating point", which is the way the number is represented in the computer. But `Double`? Why is `Double` a double-precision float, not a double-wide integer, or a UTF-16 string, or something? Why isn't it a generic type representing a pair of same-typed instances? Unlike, for instance, `switch`/`case`/`default`, where these are plausible names you might pick even without C's influence, `Double` is pure C jargon.

- **The naming of float types is unrelated to the naming of integer types.** Swift's integer types have a rationalized, ergonomic naming scheme. Swift's float types have a haphazard naming scheme. It just doesn't feel like the same language. By matching the floating-point types' naming scheme to the integer types, you can bring your knowledge of the integer types over to the floating-point types.

···

--
Brent Royal-Gordon
Architechies

[Janosch_Hildebrand]

a) That ‘Double’ is not a great type name and the Float/Double combination is inconsistent naming.
(b) Trying to direct this discussion into a (from my point of view) more reasonable direction; i.e. away from 64-bit Float and CGFloat-reborn)

Although I wouldn’t go so far as to call Float/Double a problem, more of a nitpick.
I hadn’t given it any thought really before this thread so this is just me thinking out loud…

To me, FloatXX has the following advantages:
Consistent naming: Float16, Float32, Float80, Float128
The names contain information about the type (what is it, how large is it) that is very accessible
Aligns nicely with the integer types

And the following obvious disadvantages:
Float and Double are much more prevalent (
Float and Double are shorter

However I think the decision to go with Float/Double is very reasonable as these advantages are pretty minor and on the other end of the scale is a lot of historical precedent. Hence the ‘can we get people used to and using FloatXX while still retaining Float & Double?’ ;-)

- Janosch

···

On 06 Jan 2016, at 03:08, Chris Lattner <clattner@apple.com> wrote:

On Jan 5, 2016, at 4:41 PM, Janosch Hildebrand via swift-evolution <swift-evolution@swift.org> wrote:

I also think that Float and Double are not ideal type names but I also agree with many of the concerns that have been raised.

Why not simply use (the existing) Float32 and Float64 while keeping everything else equal?

What perceived problem are you solving?

-Chris

[David_Sweeris]

I'd prefer they mirror the integer type naming "conventions", that is have an explicit "Float32" and "Float64" type, with "Float" being a typealias for Float64.

···

Sent from my iPhone

On May 23, 2016, at 18:26, Adriano Ferreira via swift-evolution <swift-evolution@swift.org> wrote:

Hi everyone,

Is there any draft/proposal related to this suggestion?

Best,

— A

On Jan 4, 2016, at 3:58 PM, Alex Johnson via swift-evolution <swift-evolution@swift.org> 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".

What if the name "Float" were given to the intrinsic, 64-bit floating point type? (And the existing "Float" and "Double" names were removed in favor of "Float32" and "Float64"?)

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.

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.
Another corollary: Swift needs to interoperate with Objective C, and its "float" and "double" types.
Renaming these types would open the door to bike-shedding every type name and keyword in the language.
Changing the meaning of an existing type ("Float") would be a bit PITA for existing code (although an automated migration from "Float" to "Float32" and "Double" to "Float" should be possible).
Renaming a fundamental type would take considerable effort.
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?
(that last one is a joke, BTW)

What do you think? Do you agree or disagree with any of my assessments? Are there any pros or cons that I've missed? Is the level of effort so large that it makes this change impractical? Is it a colossal waste of human effort to even consider a change like this?

Thanks for your time and attention,
Alex Johnson (@nonsensery)
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Chris_Lattner]

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.

-Chris

···

On Jan 5, 2016, at 11:20 AM, Goffredo Marocchi <panajev@gmail.com> 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.

[Alex_Johnson]

Just to clarify: I was suggesting removing the name "Double" and giving a
different meaning to the name "Float".

~ Alex

These are functionally different cases. We are *omitting* a C feature by

···

On Tue, Jan 5, 2016 at 11:51 AM, Chris Lattner <clattner@apple.com> wrote:

removing ++ and --. This proposal included keeping the name “Double” but
giving it a different meaning.

[Kevin_Wooten]

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

[Paul_Cantrell]

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@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@apple.com <mailto:clattner@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[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@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@swift.org <mailto:swift-evolution@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@apple.com <mailto:clattner@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[jrose (Jordan Rose)]

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

···

On Jan 5, 2016, at 13:22, Kevin Wooten via swift-evolution <swift-evolution@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.

[James_Campbell]

Is there a reason we need a Double as well as a Float ? I see the value in
Int and Float butt could they not both be the biggest value supported on
the platform?

Usually when mapped to Objective-C Swift values become NSIntegers anyways
which I don't believe is a pure float or double.

···

On Tue, Jan 5, 2016 at 7:20 PM, Goffredo Marocchi via swift-evolution < swift-evolution@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.

Sent from my iPhone

On 5 Jan 2016, at 18:40, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote:

On Jan 4, 2016, at 12:58 PM, Alex Johnson via swift-evolution < > swift-evolution@swift.org> 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):

   1. "Double" and "Float" are more natural for developers who are
   "familiar with C-like languages."
   2. 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*:

   1. 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".
   2. 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").
   3. Apple's Objective C APIs generally use aliased types like "CGFloat"
   rather than raw float or double types.
   4. There is precedent for "Float" types being 64-bit in other
   languages like Ruby, Python and Go (as long as the hardware supports it).
   5. 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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
 Wizard
james@supmenow.com
+44 7523 279 698

[John_Randolph]

Well, CGFloat has a specific purpose, which is for calculations having to do with things that are drawn on a display. If you need guaranteed precision in your model layer, you should be using Double and convert as needed.

-jcr

···

On Jan 6, 2016, at 12:01 AM, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org> wrote:
This is the biggest problem I had with CGFloat: while it is nice at first to have a type that adapts to the device word size it runs on, I prefer to always have an explicit accuracy guarantee than worrying about my CGFloat code changing in behaviour when it runs on a 32 bit device rather than a 64 bit one.