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

Path to Stage 4! #1

Open
22 of 42 tasks
gibson042 opened this issue Sep 27, 2024 · 12 comments
Open
22 of 42 tasks

Path to Stage 4! #1

gibson042 opened this issue Sep 27, 2024 · 12 comments

Comments

@gibson042
Copy link
Collaborator

gibson042 commented Sep 27, 2024

Stage 4

  • committee approval
  • two implementations
    • JavaScriptCore
    • SpiderMonkey
    • XS
    • V8
  • significant in-the-field experience
  • ecma262 PR approved
  • prepare ecma262 PR

Stage 3

Stage 2.7

Stage 2

  • committee approval
  • spec reviewers selected
  • spec text written

Stage 1

  • committee approval
@erights
Copy link
Collaborator

erights commented Jan 10, 2025

@syg @waldemarhorwat @ljharb , with the normative issues resolved aside from the purposely postponed #16 (see checklist above), This seems ready for spec review. I have placed this item on the agenda to go for 2.7, so would like to be as prepared as possible.

For the "spec editor signoff", who are the spec editors?

@syg
Copy link

syg commented Jan 10, 2025

You can tag @tc39/ecma262-editors. Currently the editors are myself, @bakkot, and @michaelficarra.

@erights erights mentioned this issue Feb 15, 2025
8 tasks
@erights
Copy link
Collaborator

erights commented Feb 17, 2025

@syg @waldemarhorwat @bakkot @michaelficarra ping.

@syg @bakkot please see @gibson042 responses to your stated concerns. What remaining concerns do you have that should block 2.7 until resolved?

@waldemarhorwat @michaelficarra I'd love to see your feedback before asking for stage 2.7.

Thanks!

@syg
Copy link

syg commented Feb 18, 2025

Current spec draft editorially and normatively lgtm for 2.7.

@waldemarhorwat
Copy link

Looks good to me, with just one comment:

  • Why does sliceToImmutable diverge from slice when end < start? That seems like needless inconsistency. Having one of these clamp to zero and one throw will confuse users and cause subtle bugs if someone refactors sliceToImmutable to slice.

@ljharb
Copy link
Member

ljharb commented Feb 18, 2025

(no opinion on the outcome) but wouldn't the exception prevent subtle bugs caused by the clamping, by throwing?

@waldemarhorwat
Copy link

See my comment above. Hardly anyone will remember which one clamps and which one throws, so folks relying on throwing will be in for a rude surprise.

@ljharb
Copy link
Member

ljharb commented Feb 18, 2025

ahhh gotcha, you mean going "backwards". fair point.

@gibson042
Copy link
Collaborator Author

Why does sliceToImmutable diverge from slice when end < start? That seems like needless inconsistency.

Producing a zero-length immutable buffer from code like buf.sliceToImmutable(4, 2) was deemed so useless and undesirable that an exception was warranted even with divergence from ArrayBuffer.prototype.slice. But it's true that every method named slice performs such clamping, and maybe that counterpoint is heavy enough to justify internal consistency here.

@erights
Copy link
Collaborator

erights commented Feb 18, 2025

@waldemarhorwat I think this is explicitly covered by #16 , which is still open. We felt that for the sake of concreteness it was better for the champions to specify according to their preferences at the moment, as long as there is an open issue covering the remaining controversy.

In any case, I agree with @gibson042 here, that we are open to removing this difference with slice.

Given that, may we check your 2.7 reviewer checkbox (just in time for my presentation ;) )

@gibson042
Copy link
Collaborator Author

Why does sliceToImmutable diverge from slice when end < start? That seems like needless inconsistency.

#41

erights added a commit that referenced this issue Feb 19, 2025
Normative: Align ArrayBuffer sliceToImmutable length clamping with slice

as suggested by @waldemarhorwat. Thanks!
@erights
Copy link
Collaborator

erights commented Feb 19, 2025

@gibson042 , thanks!

I just approved and merged #41

@waldemarhorwat , in light of your verbal agreement, I'm clicking your checkbox. If we've misunderstood anything, please uncheck and let us know.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants