Re: [Json] JSON Schema Language: int53

[Ulysse Carion <[e-mail]>]

> I’m not quite sure what “implementing a pseudo-type” means, but is that hard?

Not hard. It means creating some sort of type/struct/class that has
ToLong/FromLong as methods, and at runtime checks that the values are
in range.

The problem with this approach (I've tried it, briefly) is that for
real-world code that means you end up needing to jump through these
ToLong/FromLong hoops in order to get work done. If added, this would
be the only such inconvenient hoop to jump through. The fact that
there's this hoop to jump through also reduces the strength of James's
point -- that without int53, you would never codegen "long" from
schemas. In fact, even with int53, you still don't generate "long",
you generate a type that's similar but inconveniently different from
it.

Or, as James suggests, you can generate "long" and not worry about
doing bounds checks. But then you lose the property that if you
generate some datatype X from a schema S, that all instances of X,
when serialized as JSON, satisfy S.

> Now you are in the prescriptive area — you no longer describe JSON formats, but you impose your own rules on what these data formats can be.  Not so good.

I agree. I mentioned this only to clarify what I felt was a better
approach for reconciling our desire for int64_t with the realities of
I-JSON. There is no good way to have something that produces int64_t
in the spec, in my view (gRPC inherited int64 from Protobuf, and
that's why they were forced to be prescriptive). Better to be
unopinionated, and have people implement int53 themselves on top of {
"type": "float64" }. I'd prefer to miss a feature than to include a
wart.

I think that a lot of this conversation might be clarified if I just
publish an I-D with what I have so far. Expect another thread soon.

P.S.: I recognize your point about the type perhaps being better named
"int54", Carsten. For the sake of continuity of conversation, I here
used the "misnomer". Happy to change what we're calling it, as long as
it doesn't confuse anyone.

On Thu, Aug 22, 2019 at 10:02 PM Carsten Bormann <[e-mail]> wrote:
>
> On Aug 22, 2019, at 23:54, Ulysse Carion <[e-mail]> wrote:
> >
> >> If you omit int53, then your code generation will never create a long despite this being a widely available & useful type.
> >
> > The issue, in my view, is that int64/uint64 is the widely-available
> > and useful type. Not int53. To support int53 would require that code
> > generators implement this psuedo-type at runtime.
>
> I’m not quite sure what “implementing a pseudo-type” means, but is that hard?
>
> > Consider that gRPC, which has a canonical representation in JSON and
> > which also has int64/uint64, unconditionally renders these types as
> > strings. I feel that this approach is more reasonable, as it removes
> > the footgun of a datatype that most users will assume is equivalent to
> > the familiar int64, but is not.
>
> Now you are in the prescriptive area — you no longer describe JSON formats, but you impose your own rules on what these data formats can be.  Not so good.
>
> Grüße, Carsten
>