-
Notifications
You must be signed in to change notification settings - Fork 168
Normative: Validate unit-valued options after all options are read #3130
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #3130 +/- ##
=======================================
Coverage 96.85% 96.85%
=======================================
Files 21 21
Lines 9983 9983
Branches 1829 1829
=======================================
Hits 9669 9669
Misses 268 268
Partials 46 46 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
70fa5fa
to
b3f6a0f
Compare
The code that changes behavior with this PR is something like: obj = {
get largestUnit() {
console.log("get largestUnit");
return "years";
},
get smallestUnit() {
console.log("get smallestUnit");
return "seconds";
},
}
Temporal.PlainTime.from("00:00").round(obj) Current behavior: console logs "get largestUnit" and then RangeError is thrown. New behavior: console logs both "get largestUnit" and "get smallestUnit", and then RangeError is thrown. Note: the RangeError is because PlainTime does not allow (as noted previously, there doesn't appear to be Test262 coverage for this) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The intended changes as I understand them do seem both reasonable and narrow, but I think the algorithms steps fail to properly implement them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is roughly what I was imagining, thanks for doing all this work!
As Richard has noted, handling unset/default values may be tricky. The way I was expecting it to work was that the get allows you to specify REQUIRED, and Validate doesn't need to care, which roughly appears to be what you're doing here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm surprised that this didn't show up in more places. But I guess smallestUnit
is often the last option read anyway, because S is relatively late in the alphabet. So I'm pleasantly surprised at the small extent of the normative change. (I am assuming this PR is the full extent of the changes!)
All in all I'd still prefer not to do this. (It isn't a bug in the proposal, it sets a new precedent that TC39 hasn't really shown appetite for so far, and I just don't see the alternative workaround in temporal_rs as that big of a deal.) But it's small and targeted enough that if I'm the only opposing voice, I won't stand in the way.
Logistical note: to make the best impression when presenting to TC39, I'd recommend squashing the fixup commits into their appropriate editorial or normative commits, then splitting out the editorial commit into its own PR which I can review quickly and merge. That way, there's less for delegates to review and it's much clearer what is changing.
This PR fixes the issues involving unit-valued options, which is the current scope of the issue and all I'm asking for at this time. Yes, often smallestUnit is the final read, so no change was needed in those cases. Yes, splitting the editorial change into its own PR is something I'm happy to do. |
@anba Do you have any concerns about this change? |
I opened #3135 for the editorial changes. |
The editorial changes are merged, and I rebased this. So now it's just the minimal set of normative changes. |
I don't think so. It'll require some small refactoring because the current SM implementation sometimes uses (The SM implementation already parses the unit options accepting all units and only later check which units are actually allowed. ) |
See #3116
This preserves the original call to
GetOption
, but it always calls it with the full list of units, and I pull the subset-checking logic into a separate AO.I have two commits: an editorial change to split the AO in two, and a small normative change to move the validation later down at the call sites.
@nekevss @Manishearth