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 <[email protected]>, wrote: > I'm +1 on this. > > > On Mon, 24 Jul 2017 at 15:37 Niels Andriesse via swift-evolution > > <[email protected]> wrote: > > > And CustomStringConvertible (to String) is basically the inverse of > > > LosslessStringConvertible (from String). > > > > On Mon, Jul 24, 2017 at 3:23 PM, Niels Andriesse > > > > <[email protected]> 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 > > > > > > <[email protected]> wrote: > > > > > > > > > > > > > > On Jul 23, 2017, at 09:15, Matheus Martins via swift-evolution > > > > > > > <[email protected]> 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: > > > > > > > > http://swiftdoc.org/v3.0/protocol/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. > > > > > > > > > > > > > > - Dave Sweeris > > > > > > > > > > > > > > _______________________________________________ > > > > > > > swift-evolution mailing list > > > > > > > [email protected] > > > > > > > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > > > > > > > > > > > > _______________________________________________ > > > swift-evolution mailing list > > > [email protected] > > > https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
