I came across what i think is an inconsistency in the standard library.
Why are some numeric types like Int not conforming to
LosslessStringConvertible by default while Float and Double do conform to
it in the standard library?
I came across this while trying to write some generic code:
It seems rather inconsistent to me that that allows me to do:
let floats: [Float] = array("1.0 2.2 3")
but i can't do:
let ints: [Int] = array("1 2 3 4 5 6")
"type 'Int' does not conform to protocol 'LosslessStringConvertible'"
To further my point, Int is used as the sole example in the
LosslessStringConvertible docs:
Yet it does not actually conform to it.
This seems way too basic for me to feel comfortable pitching it here, but i
searched and couldn't find any discussion on this on any mailing list or
website.
Sounds like it's a bug to me, either in the docs or stdlib, depending on the intended behavior. Although I doubt they would've used Int in the docs if they weren't intending Int to conform to it.
- Dave Sweeris
···
On Jul 23, 2017, at 09:15, Matheus Martins via swift-evolution <swift-evolution@swift.org> wrote:
I came across what i think is an inconsistency in the standard library.
Why are some numeric types like Int not conforming to LosslessStringConvertible by default while Float and Double do conform to it in the standard library?
I came across this while trying to write some generic code:
It seems rather inconsistent to me that that allows me to do:
let floats: [Float] = array("1.0 2.2 3")
but i can't do:
let ints: [Int] = array("1 2 3 4 5 6")
"type 'Int' does not conform to protocol 'LosslessStringConvertible'"
To further my point, Int is used as the sole example in the LosslessStringConvertible docs: LosslessStringConvertible — SwiftDoc.org
Yet it does not actually conform to it.
This seems way too basic for me to feel comfortable pitching it here, but i searched and couldn't find any discussion on this on any mailing list or website.
Just want to point out that conforming Int to LosslessStringConvertible like
this would mean assuming a radix of 10 in the implementation. That said,
this would be consistent with the way Int implements CustomStringConvertible,
which also uses a radix of 10.
···
On Mon, Jul 24, 2017 at 4:36 AM, David Sweeris via swift-evolution < swift-evolution@swift.org> wrote:
On Jul 23, 2017, at 09:15, Matheus Martins via swift-evolution < > swift-evolution@swift.org> wrote:
I came across what i think is an inconsistency in the standard library.
Why are some numeric types like Int not conforming to
LosslessStringConvertible by default while Float and Double do conform to
it in the standard library?
I came across this while trying to write some generic code:
It seems rather inconsistent to me that that allows me to do:
let floats: [Float] = array("1.0 2.2 3")
but i can't do:
let ints: [Int] = array("1 2 3 4 5 6")
"type 'Int' does not conform to protocol 'LosslessStringConvertible'"
To further my point, Int is used as the sole example in the
LosslessStringConvertible docs: Protocols — SwiftDoc.org
LosslessStringConvertible/
Yet it does not actually conform to it.
This seems way too basic for me to feel comfortable pitching it here, but
i searched and couldn't find any discussion on this on any mailing list or
website.
Sounds like it's a bug to me, either in the docs or stdlib, depending on
the intended behavior. Although I doubt they would've used Int in the docs
if they weren't intending Int to conform to it.
And CustomStringConvertible (to String) is basically the inverse of
LosslessStringConvertible (from String).
···
On Mon, Jul 24, 2017 at 3:23 PM, Niels Andriesse <andriesseniels@gmail.com> wrote:
Just want to point out that conforming Int to LosslessStringConvertible like
this would mean assuming a radix of 10 in the implementation. That said,
this would be consistent with the way Int implements CustomStringConvert
ible, which also uses a radix of 10.
On Mon, Jul 24, 2017 at 4:36 AM, David Sweeris via swift-evolution < > swift-evolution@swift.org> wrote:
On Jul 23, 2017, at 09:15, Matheus Martins via swift-evolution < >> swift-evolution@swift.org> wrote:
I came across what i think is an inconsistency in the standard library.
Why are some numeric types like Int not conforming to
LosslessStringConvertible by default while Float and Double do conform to
it in the standard library?
I came across this while trying to write some generic code:
It seems rather inconsistent to me that that allows me to do:
let floats: [Float] = array("1.0 2.2 3")
but i can't do:
let ints: [Int] = array("1 2 3 4 5 6")
"type 'Int' does not conform to protocol 'LosslessStringConvertible'"
To further my point, Int is used as the sole example in the
LosslessStringConvertible docs: http://swiftdoc.org/v3.0/proto
col/LosslessStringConvertible/
Yet it does not actually conform to it.
This seems way too basic for me to feel comfortable pitching it here, but
i searched and couldn't find any discussion on this on any mailing list or
website.
Sounds like it's a bug to me, either in the docs or stdlib, depending on
the intended behavior. Although I doubt they would've used Int in the docs
if they weren't intending Int to conform to it.
On Mon, 24 Jul 2017 at 15:37 Niels Andriesse via swift-evolution < swift-evolution@swift.org> wrote:
And CustomStringConvertible (to String) is basically the inverse of
LosslessStringConvertible (from String).
On Mon, Jul 24, 2017 at 3:23 PM, Niels Andriesse <andriesseniels@gmail.com > > wrote:
Just want to point out that conforming Int to LosslessStringConvertible like
this would mean assuming a radix of 10 in the implementation. That said,
this would be consistent with the way Int implements
CustomStringConvertible, which also uses a radix of 10.
On Mon, Jul 24, 2017 at 4:36 AM, David Sweeris via swift-evolution < >> swift-evolution@swift.org> wrote:
On Jul 23, 2017, at 09:15, Matheus Martins via swift-evolution < >>> swift-evolution@swift.org> wrote:
I came across what i think is an inconsistency in the standard library.
Why are some numeric types like Int not conforming to
LosslessStringConvertible by default while Float and Double do conform to
it in the standard library?
I came across this while trying to write some generic code:
It seems rather inconsistent to me that that allows me to do:
let floats: [Float] = array("1.0 2.2 3")
but i can't do:
let ints: [Int] = array("1 2 3 4 5 6")
"type 'Int' does not conform to protocol 'LosslessStringConvertible'"
To further my point, Int is used as the sole example in the
LosslessStringConvertible docs: LosslessStringConvertible — SwiftDoc.org
Yet it does not actually conform to it.
This seems way too basic for me to feel comfortable pitching it here,
but i searched and couldn't find any discussion on this on any mailing list
or website.
Sounds like it's a bug to me, either in the docs or stdlib, depending on
the intended behavior. Although I doubt they would've used Int in the docs
if they weren't intending Int to conform to it.
I think this is a bug. Basing on other numeric types, the intended result would be the same for Int.
···
On 26 Jul 2017, 7:40 AM +0800, Niels Andriesse via swift-evolution <swift-evolution@swift.org>, wrote:
I'm +1 on this.
> On Mon, 24 Jul 2017 at 15:37 Niels Andriesse via swift-evolution <swift-evolution@swift.org> wrote:
> > And CustomStringConvertible (to String) is basically the inverse of LosslessStringConvertible (from String).
> > > On Mon, Jul 24, 2017 at 3:23 PM, Niels Andriesse <andriesseniels@gmail.com> wrote:
> > > > Just want to point out that conforming Int to LosslessStringConvertible like this would mean assuming a radix of 10 in the implementation. That said, this would be consistent with the way Int implements CustomStringConvertible, which also uses a radix of 10.
> > > >
> > > > > On Mon, Jul 24, 2017 at 4:36 AM, David Sweeris via swift-evolution <swift-evolution@swift.org> wrote:
> > > > > >
> > > > > > On Jul 23, 2017, at 09:15, Matheus Martins via swift-evolution <swift-evolution@swift.org> wrote:
> > > > > >
> > > > > > > I came across what i think is an inconsistency in the standard library.
> > > > > > >
> > > > > > > Why are some numeric types like Int not conforming to LosslessStringConvertible by default while Float and Double do conform to it in the standard library?
> > > > > > >
> > > > > > > I came across this while trying to write some generic code:
> > > > > > >
> > > > > > > func array<T: LosslessStringConvertible>(_ text: String) -> [T?] {
> > > > > > > return text.components(separatedBy: " ").map { T($0) }
> > > > > > > }
> > > > > > >
> > > > > > > It seems rather inconsistent to me that that allows me to do:
> > > > > > >
> > > > > > > let floats: [Float] = array("1.0 2.2 3")
> > > > > > >
> > > > > > > but i can't do:
> > > > > > >
> > > > > > > let ints: [Int] = array("1 2 3 4 5 6")
> > > > > > > "type 'Int' does not conform to protocol 'LosslessStringConvertible'"
> > > > > > >
> > > > > > > To further my point, Int is used as the sole example in the LosslessStringConvertible docs: LosslessStringConvertible — SwiftDoc.org
> > > > > > > Yet it does not actually conform to it.
> > > > > > >
> > > > > > > This seems way too basic for me to feel comfortable pitching it here, but i searched and couldn't find any discussion on this on any mailing list or website.
> > > > > >
> > > > > > Sounds like it's a bug to me, either in the docs or stdlib, depending on the intended behavior. Although I doubt they would've used Int in the docs if they weren't intending Int to conform to it.
> > > > > >
> > > > > > - Dave Sweeris
> > > > > >
> > > > > > _______________________________________________
> > > > > > 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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
Agree. The approved text of SE-0089 explicitly contemplates Int conforming
to LosslessStringConvertible. This would mean that it's a bug that the
conformance hasn't been implemented.
···
On Tue, Jul 25, 2017 at 8:03 PM, Angelo Villegas via swift-evolution < swift-evolution@swift.org> wrote:
I think this is a bug. Basing on other numeric types, the intended result
would be the same for Int.
On 26 Jul 2017, 7:40 AM +0800, Niels Andriesse via swift-evolution < > swift-evolution@swift.org>, wrote:
I'm +1 on this.
On Mon, 24 Jul 2017 at 15:37 Niels Andriesse via swift-evolution < > swift-evolution@swift.org> wrote:
And CustomStringConvertible (to String) is basically the inverse of
LosslessStringConvertible (from String).
On Mon, Jul 24, 2017 at 3:23 PM, Niels Andriesse < >> andriesseniels@gmail.com> wrote:
Just want to point out that conforming Int to LosslessStringConvertible like
this would mean assuming a radix of 10 in the implementation. That said,
this would be consistent with the way Int implements CustomStringConvert
ible, which also uses a radix of 10.
On Mon, Jul 24, 2017 at 4:36 AM, David Sweeris via swift-evolution < >>> swift-evolution@swift.org> wrote:
On Jul 23, 2017, at 09:15, Matheus Martins via swift-evolution < >>>> swift-evolution@swift.org> wrote:
I came across what i think is an inconsistency in the standard library.
Why are some numeric types like Int not conforming to
LosslessStringConvertible by default while Float and Double do conform to
it in the standard library?
I came across this while trying to write some generic code:
It seems rather inconsistent to me that that allows me to do:
let floats: [Float] = array("1.0 2.2 3")
but i can't do:
let ints: [Int] = array("1 2 3 4 5 6")
"type 'Int' does not conform to protocol 'LosslessStringConvertible'"
To further my point, Int is used as the sole example in the
LosslessStringConvertible docs: Protocols — SwiftDoc.org
LosslessStringConvertible/
Yet it does not actually conform to it.
This seems way too basic for me to feel comfortable pitching it here,
but i searched and couldn't find any discussion on this on any mailing list
or website.
Sounds like it's a bug to me, either in the docs or stdlib, depending
on the intended behavior. Although I doubt they would've used Int in the
docs if they weren't intending Int to conform to it.