ICU-22284 dump Numeric_Value property in icuexportdata.cpp #3751
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
currently, there is no way to get the numeric value of a character from the icuexportdata, so this exports the values into a
nv.tomlfile. this is a value, that icu4x would like to be able to provide (unicode-org/icu4x#3014).for the newsimilar to thenv.tomlexport, i added a new type of property, a[[value_property]]. a value property is similar to an[[enum_property]], but it doesn't have thevalueskey for the enum variants and it doesn't have anamefield for each of the range maps.bmg.toml, this exports a[[enum_property]], but without thevaluesand without thenamefield in each of the ranges.i was a little unsure, of what value to export, as there were two options: exporting it as a double or exporting the raw numeric type value (via
GET_NUMERIC_TYPE_VALUE(u_getMainProperties(c))). i have decided on the second, both for being smaller (adoublevs anint32_t) and for being more accurate (floating point numbers cannot accurately represent some fractions and the highest number that unicode provides is higher than the max safe integer of a double). it is also more flexible, potentially allowing languages with native support for fractions to actually consume them as fractions. this does put the burden of reinterpreting the value again on the consumer side, but i think, that is a fine tradeoff.i have also made a icu4x branch, where i provide this new property: https://github.com/m4rch3n1ng/icu4x/tree/numeric-value. you can also see how the new nv.toml file looks like there.
Checklist