Skip to content
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

Editorial: Note how edge case in GetSubstitution can arise #2603

Merged
merged 1 commit into from
Jan 20, 2022

Conversation

bakkot
Copy link
Contributor

@bakkot bakkot commented Dec 30, 2021

This adds the note I suggested here.

It's a bit wordy because the edge case can only happen in very specific circumstances. I'm very open to suggestions for improved wording here.

@ljharb ljharb requested review from michaelficarra, syg and a team December 30, 2021 07:13
spec.html Outdated
@@ -33899,6 +33899,7 @@ <h1>
1. Let _matchLength_ be the number of code units in _matched_.
1. Let _tailPos_ be _position_ + _matchLength_.
1. Let _refReplacement_ be the substring of _str_ from min(_tailPos_, _stringLength_).
1. NOTE: _tailPos_ can exceed _stringLength_ if and only if this abstract operation was invoked by a call to the intrinsic @@replace method of %RegExp.prototype% on an object whose *"exec"* property is not the intrinsic %RegExp.prototype.exec%.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"if an only if" suggests necessary and sufficient, but presumably the condition isn't sufficient. I.e. it alone doesn't guarantee that _tailPos_ will exceed _stringLength_. So I think delete "if and".

Also, I think it's the necessary condition only if you assume that intrinsics have their initial settings. E.g., if String.p.replace is something other than %String.p.replace%, then aren't all bets off on how it might invoke GetSubstitution? So maybe it would be better to phrase the note as one way that the weirdness can happen. (Or maybe, the only way it can happen using spec-defined algorithms?)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nothing has access to GetSubstitution except the builtin methods.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

An implementation can supply a non-standard function; can't its semantics be defined using abstract operations such as GetSubstitution?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose that's true, but I don't think this spec needs to consider that scenario, ever. AOs aren't an API.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point about if, will fix.

Re: other specs calling this algorithm, I agree with @ljharb - we have no control over how other specs invoke our AOs, but we don't usually let that stop us from writing down useful invariants which hold within this document. (And, as a practical matter, I really don't think any other spec would want to call GetSubstitution.)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AOs aren't an API.

True, though I don't think there's anything stopping an implementation (or another specification) from treating them as such.

@bakkot bakkot added the ready to merge Editors believe this PR needs no further reviews, and is ready to land. label Jan 19, 2022
@ljharb ljharb force-pushed the note-exec-weirdness branch from 7cf6a91 to ba8ebd2 Compare January 20, 2022 03:49
@ljharb ljharb merged commit ba8ebd2 into main Jan 20, 2022
@ljharb ljharb deleted the note-exec-weirdness branch January 20, 2022 04:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
editorial change ready to merge Editors believe this PR needs no further reviews, and is ready to land.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants