On 2017-08-14 11:07, Markus Armbruster wrote: > Max Reitz writes: > >> On 2017-07-11 13:33, Markus Armbruster wrote: >>> Max Reitz writes: >>> >>>> First of all, OK, you don't want QNum(42.0) to equal QNum(42) at all (at >>>> least not right now and in the foreseeable future). >>>> You're the maintainer, so you decide, so I'll go along with it. :-) >>>> >>>> Now, let's follow up with my therefore rather useless commentary: >>>> >>>> (Feel free to disregard, because honestly, I can see how replying to >>>> most of the points I'm asking isn't really worth the time...) >>> >>> When I use the authority entrusted to maintainers, I feel obliged to at >>> least explain my reasoning. Besides, putting my reasoning in words >>> tends to lead me to new insights. >> >> And I am indeed very grateful for that. :-) >> >>>> On 2017-07-10 11:17, Markus Armbruster wrote: >>>>> Max Reitz writes: >>>>> >>>>>> On 2017-07-06 16:30, Markus Armbruster wrote: >> >> [...] >> >>>>> The only way to add unsigned integers without breaking QMP compatibility >>>>> is to make them interchangeable with signed integers. That doesn't mean >>>>> you get to make floating-point numbers interchangeable with integers >>>>> now. >>>> >>>> Again, begs the question why QNum covers floating point numbers then and >>>> why this very fact is not documented in qnum.c. >>> >>> What kind of documentation would you like to see? >> >> It would be good to note that the QNum type is not meant to be a >> completely uniform way to handle JSON numbers (e.g. if the user provides >> something with a decimal point but you need an integer, QNum will not do >> that conversion for you). >> >> It is (English indirect speech is broken badly) just meant to >> encapsulate the different variants a number can be represented in, but >> you're still generally supposed to read it out the way it was put in >> (exceptions apply, see signed/unsigned and qnum_get_double()). > > Can we distill this into text that could become an actual patch? Let me > try. > > QNum encapsulates how our dialect of JSON fills in the blanks left > by the JSON specification (RFC 7159) regarding numbers. > > Conceptually, we treat number as an abstract type with three > concrete subtypes: floating-point, signed integer, unsigned integer. > QNum implements this a discriminated union of double, int64_t, > uint64_t. > > The JSON parser picks the subtype as follows. If the number has a > decimal point or an exponent, it is floating-point. Else if it fits > into int64_t, it's signed integer. Else if it first into uint64_t, > it's unsigned integer. Else it's floating-point. > > Any number can serve as double: qnum_get_double() converts under the > hood. > > An integer can serve as signed / unsigned integer as long as it is > in range: qnum_get_try_int() / qnum_get_try_uint() check range and > convert under the hood. > > What do you think? Sounds very good to me, thanks! Max