So, as I understand it, `Float.init(exactly: Double.pi) == nil`. I would expect NSNumber to behave similarly (a notion with which Martin disagrees, I guess). I don't see a test that shows whether NSNumber behaves or does not behave in that way.
On Tue, Apr 18, 2017 at 11:43 AM, Philippe Hausler <phaus...@apple.com> wrote: > > On Apr 18, 2017, at 9:22 AM, Stephen Canon <sca...@apple.com> wrote: > > > On Apr 18, 2017, at 12:17 PM, Joe Groff <jgr...@apple.com> wrote: > > > On Apr 17, 2017, at 5:56 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > It seems Float.init(exactly: NSNumber) has not been updated to behave > similarly? > > I would have to say, I would naively expect "exactly" to behave exactly as > it says, exactly. I don't think it should be a synonym for > Float(Double(exactly:)). > On Mon, Apr 17, 2017 at 19:24 Philippe Hausler via swift-evolution < > swift-evolution@swift.org> wrote: > I posted my branch and fixed up the Double case to account for your > concerns (with a few inspired unit tests to validate) > > https://github.com/phausler/swift/tree/safe_nsnumber > > There is a builtin assumption here though: it does presume that the > swift’s representation of Double and Float are IEEE compliant. However that > is a fairly reasonable assumption in the tests. > > > (+Steve Canon) What is the behavior of Float.init(exactly: Double)? > NSNumber's behavior would ideally be consistent with that. > > > The implementation is essentially just: > > self.init(other) > guard Double(self) == other else { > return nil > } > > i.e. if the result is not equal to the source when round-tripped back to > double (which is always exact), the result is nil. > > – Steve > > > Pretty much the same trick inside of CFNumber/NSNumber >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
