tc39/proposal-immutable-arraybuffer

Path to Stage 4!

gibson042 opened this issue · 13 comments

gibson042 commented

Stage 4

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

Stage 3

  • committee approval
  • merge test262 tests
  • write test262 tests
  • receive implementer feedback
  • resolve all normative stage 4 issues
    • #44
    • #16 was not a normative requirement for 2.7. It is normative for stage 3

Stage 2.7

Stage 2

  • committee approval
  • spec reviewers selected
  • spec text written

Stage 1

  • committee approval
erights commented

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

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

  • 👍1
erights commented

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

Current spec draft editorially and normatively lgtm for 2.7.

waldemarhorwat commented

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 commented

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

waldemarhorwat commented

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.

  • 👍1
ljharb commented

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

gibson042 commented

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 commented

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

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

#41

erights commented

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

  • 👍1