Path to Stage 4!

[gibson042]

Stage 4

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

Stage 3

• committee approval
• merge test262 tests
• write test262 tests
  • testing plan
  • basic tests
• receive implementer feedback
  • XS: implemented, tested, all good
• resolve all normative stage 4 issues
  • Document the permanent bidirectional stability of immutable ArrayBuffer contents #44
  • Order of operations, when to throw or silently do nothing? #16 was not a normative requirement for 2.7. It is normative for stage 3

Stage 2.7

• committee approval
• spec editor signoff (@tc39/ecma262-editors)
  • Shu-yu Guo (@syg) (see Review #30)
  • Kevin Gibbons (@bakkot) (see bakkot editor review #31 (comment))
  • Michael Ficarra (@michaelficarra) (verbally deferred to @syg and @bakkot)
• spec reviewer signoff
  • Shu-yu Guo (@syg) (see Review #30)
  • Waldemar Horwat (@waldemarhorwat) (see Normative: Align ArrayBuffer sliceToImmutable length clamping with slice #41)
  • Jordan Harband (@ljharb) (see Spec Review #27 (comment))
• resolve all normative issues
  • Should transferToImmutable support a newByteLength argument? #15
    • Yes. Resolved and closed
  • .immutable or .mutable? #10
    • .immutable for easy upgrade. Resolved and closed
  • add .sliceToImmutable? #9
    • Yes. Resolved and closed
  • Order of operations, when to throw or silently do nothing? #16
    • Purposely left open for more implementor feedback
• status of non-normative issues
  • Applicability to WebGPU buffer mapping #25
    • No. This proposal not applicable to WebGPU, but Limited ArrayBuffer may be.
  • Mention proposed integration with "structured cloning" #19
    • Yes. See Add immutable array buffer awareness to structuredClone whatwg/html#11033
  • Zero-copy operations on the web #18
    • Mixed bag. See Prior proposals or issues with overlapping goals
  • Update shim according to issue resolutions #26
    • Yes. See fix(immutable-arraybuffer): update to recent spec endojs/endo#2688
• receive implementer feedback
  • XS implementation good. Does not suggest any changes.
  • shim implementation and practical use is necessarily incomplete, but does not suggest any changes.
  • others...?

Stage 2

• committee approval
• spec reviewers selected
  • Shu-yu Guo (@syg)
  • Waldemar Horwat (@waldemarhorwat)
  • Jordan Harband (@ljharb)
• spec text written

Stage 1

• committee approval

[erights]

@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]

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

[erights]

@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]

Current spec draft editorially and normatively lgtm for 2.7.

[waldemarhorwat]

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]

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

[waldemarhorwat]

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]

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

[gibson042]

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]

@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]

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

#41