Re: [Json] JSON Schema Language is nearly done: int53

[Ulysse Carion <[e-mail]>]

Perhaps int53 is a footgun for reasons similar to int64? Folks in practice
might pretend int53 is int64 for all intents and purposes, incurring the
same problems.

In the interest of keeping the spec small, safe, and unsurprising, I think
simply removing int64/uint64, but preserving the other types (including
less common ones like int8) may be the best option. I'd rather not
arbitrarily leave out powers of two or particular signed/unsigned variants,
nor leave in features which make it likelier that people make faulty
assumptions about interoperable JSON.

On Sun, Jul 28, 2019 at 6:02 PM Manger, James <
[e-mail]> wrote:

> > Given that introducing int64 as a JSON number type would be a footgun
> for many sorts of applications, I agree it should be changed.
>
> >
>
> > How would you feel about simply removing int64/uint64, but otherwise
> keeping everything else as-is? I don't know if adding "native" support for
> string-represented bigints is a great idea, as there are so many different
> options. Smaller specs are the ones most frequently implemented correctly
> and securely.
>
>
>
> Just removing int64/uint64 is ok. I’d prefer to have int53. It covers all
> integer cases that work sensibly. Other options (int8, unit32, etc) are
> merely nice-to-have hints that could be omitted for a smaller spec.
>
>
>
> --
>
> James Manger
>