How do infinity and negative infinity serialize?

[sfackler]

The spec indicates that doubles serialize as number | "NaN" - would infinities be treated as NaN then?

[ferozco]

thats correct

[sfackler]

conjure-java does not implement this properly:

    @Test
    public void double_nan_fields_should_be_serialized_as_a_string() throws Exception {
        assertThat(mapper.writeValueAsString(DoubleExample.of(Double.NaN)))
                .isEqualTo("{\"doubleValue\":\"NaN\"}");
    }

org.junit.ComparisonFailure: 
Expected :"{"doubleValue":"NaN"}"
Actual   :"{"doubleValue":"Infinity"}"

[sfackler]

The current wire format seems to contradict itself - in particular this doesn't hold for infinities:

Every Conjure object (including primitives, complex objects, containers, etc.) is representable as a JSON object such that, intuitively, deserialize(serialize(object)) == object.

[uschi2000]

I think we should ban Nan and infinity. // mobile

…

________________________________ From: Steven Fackler <[email protected]> Sent: Thursday, July 5, 2018 4:53:42 PM To: palantir/conjure Cc: Subscribed Subject: Re: [palantir/conjure] How do infinity and negative infinity serialize? (#33) The current wire format seems to contradict itself - in particular this doesn't hold for infinities: Every Conjure object (including primitives, complex objects, containers, etc.) is representable as a JSON object such that, intuitively, deserialize(serialize(object)) == object. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub [github.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_palantir_conjure_issues_33-23issuecomment-2D402884436&d=DwMFaQ&c=izlc9mHr637UR4lpLEZLFFS3Vn2UXBrZ4tFb6oOnmz8&r=UfcWCaR4ui50AFap-gezrx5XYtPtH-9JpazU7tbRW-4&m=ttIXm1kEu86L8sgx82vREBnq7yiWu5qMinPfpWLf4_8&s=Z6uCxb0En8m23c-czMzUn75UFvLZEmJfFkm_bwJ4SK4&e=>, or mute the thread [github.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AGOdwc89zDnTIoqBnIKqq4ole6CxZtFXks5uDqcGgaJpZM4VBnsM&d=DwMFaQ&c=izlc9mHr637UR4lpLEZLFFS3Vn2UXBrZ4tFb6oOnmz8&r=UfcWCaR4ui50AFap-gezrx5XYtPtH-9JpazU7tbRW-4&m=ttIXm1kEu86L8sgx82vREBnq7yiWu5qMinPfpWLf4_8&s=m1fd0Yewa8se2SE8x802gESNK4fRFsc8iMmdXV-2E8g&e=>.

[sfackler]

By making a SafeDouble? That seems like it's probably the best approach. Properly controlling the serialization/deserialization of NaN/Infinity consistently in arbitrary languages is going to be a pretty big pain so it'd be great to avoid the issue entirely.

[markelliot]

Pretty sure we discussed this a month ago and the plan was to:

• say that Conjure's double does not support NaN or +/-Infinity
• if necessary, add a union type called ieeedouble or something similar that is a union over Conjure's double, NaN, +Infinity, -Infinity

[uschi2000]

Yes, that ("does not support") is what I was advocating for above.

[dphilipson]

I agree with @markelliot and @uschi2000 and would like to see this changed. The current behavior of typing doubles as number | "NaN" in TypeScript forces consumers to add a lot of boilerplate, and I expect that almost nobody wants to define APIs which accept or produce NaN values. It's not even safe under the current behavior as pointed out in this thread.

[iamdanfox]

@dphilipson I've tried to capture the tradeoffs of just banning these things in the Handling double NaN and Infinity RFC... we found that the assertion "nobody wants to define APIs which accept or produce NaN values" is not quite true, as there is a plausible use case for app which render customer data, which may itself contain NaN/Infinity.

If your specific feedback is focussed on the typescript ergonomics of doubles then I think there's a typescript specific solution which is to introduce a serialization/deserialization layer so that the JSON string "NaN" received from the wire is translated into the JavaScript NaN value.

EDIT - I've opened palantir/conjure-typescript#48 to describe this proposal in more detail.