You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm writing a parser for a command registration system, and it would be nice to have the bounds for min/max value/length available as constants.
I've not tested these numbers yet, I took them from MDN with the assumption that JS is the reason 53-bit values were the bound.
While the *_length fields don't use CommandOptionValue, I think it would be appropriate to put STRING_RANGE there for discoverability. I'm recommending the use of Range here for a few reasons:
Picking a name for "the minimum of the minimum value" etc is ugly
Range::contains is convenient
Range exposes the min/max as start and end fields, so the direct values are available
This commit adds associated types for the integer and floating point
range that is allowed.
It also adds a range that contains the allowed length of a string.
Closes#2402
I'm writing a parser for a command registration system, and it would be nice to have the bounds for min/max value/length available as constants.
I've not tested these numbers yet, I took them from MDN with the assumption that JS is the reason 53-bit values were the bound.
While the
*_length
fields don't useCommandOptionValue
, I think it would be appropriate to putSTRING_RANGE
there for discoverability. I'm recommending the use ofRange
here for a few reasons:Range::contains
is convenientRange
exposes the min/max asstart
andend
fields, so the direct values are availableThe text was updated successfully, but these errors were encountered: