[stdlib] NFC: Unicode.Scalar.Properties documentation fixes

[allevato]

Non-functional cleanup/improvements missed after changes in the initial implementation PR:

• Updated the description of family emoji to be less "nuclear"
• Reference the Swift string properties *caseMapping instead of the Unicode transforms to*case in the descriptions of the Boolean changesWhen*cased properties (this change is still consistent with the definitions of those transforms)
• Remove - Returns: sections from the case mapping properties now that they're properties instead of functions
• Update description of numericValue to return nil instead of nan
• Update the code examples in numeric{Type,Value} with slightly cleaner output

ping: @milseman

[xwu]

@swift-ci please smoke test

[milseman]

Just some minor wording changes, possibly me being over-cautious.

[milseman]

This description is not quite accurate. The point about NFD is more of a specification detail, since NFD is simpler to specify properties in terms of and maintains its own normality under these mappings. But, I can't find any guarantee that lowercaseMapping produces NFD.

Also, since normalization may change one scalar into many, the spec's mention of case mapping is as applied to the resulting sequence of scalars, so it's a little odd to talk in terms of lowercaseMapping on the scalar directly.

But, we may be able to infer (and we should verify) that x.changesWhenLowercased == (String(x) == x.lowercaseMapping), as this property exists to optimize case logic fast-paths.

Strawman: "A Boolean property indicating whether the scalar's normalized form differs from the lowercaseMapping of each constituent scalar."

Though I find "each constituent scalar" a little hard to read...

[allevato]

I'll defer to your suggestion since upon re-reading them both, yours is truer to §3.13. I tried thinking of other ways to phrase "each constituent scalar" but couldn't land on anything I liked better after about 5 minutes, so let's go with that.

[milseman]

Can we validate that the "normalized" word is unnecessary? There are many scalars which are not in any normal form, so we'd want to make sure this property gives the equivalent answer as the normalized one.

[allevato]

Yeah, this one was my attempt to reword it in such a way that it avoided the fact that we didn't have a casefoldMapping property like we have the others, but that piece got lost here. Your suggestion above made it easier to reword this to be parallel to those, so I just did that instead.

[allevato]

Changes made—thanks for the suggestions! Once this is merged, can we cherrypick both #15593 and this one into the 4.2 branch?

[milseman]

Whether we can merge Unicode Scalar Properties into 4.2 would be a decision by the release managers for 4.2.

CC @airspeedswift and @tkremenek.

[airspeedswift]

@allevato I think it's a bit late in the release cycle to pick something like this over to 4.2 I'm afraid.

[allevato]

@airspeedswift No worries! I wasn't sure what the policies are around when to pick features into the release. Waiting until 5.0 gives me an opportunity to refine a few things in the interim.

[airspeedswift]

@allevato yeah if it was a small patch to just a std lib type it might still be OK, but since this interacts with ICU it probably needs a bit of time to bake on master.

[allevato]

Bump—is there anything else to be done before we can merge these changes into master?

[milseman]

@swift-ci please test and merge

[milseman]

@swift-ci please test and merge