ArrayBuffer.prototype.slice calculates a requested window, asks a species constructor to create the destination, and then checks the source again before copying. That second check matters because constructor lookup and construction can run user code that detaches or resizes the source. A correct explanation must keep the planned length, the destination contract and the source’s current state separate.
This specialist guide belongs to the Websites root. It also connects to The Gold Standard of Education | Learning That Transfers into Life and the How X Works hub. The worked cases are original teaching examples; their values and event logs are stated so each conclusion can be checked.
eduKateSG · Websites
Find your next learning step
Follow the routes to trace index conversion, species lookup, destination validation, source detachment or resizing, bounded copying and evidence that distinguishes a copied slice from transfer or resize.
ROUTE 1 · CHAPTERS 1–3
Build the first model
Name the input, state, conversion or predicate before following user-visible results.
ROUTE 2 · CHAPTERS 4–5
Trace the decisive branch
Work the accepted path and the nearest boundary case with original examples.
ROUTE 3 · CHAPTERS 6–8
Change one premise
Rebuild the mechanism when state, value, realm, timing or object kind changes.
ROUTE 4 · CHAPTERS 9–10
Handle limits and failures
Keep abrupt completion, availability and application limits visible.
ROUTE 5 · CHAPTERS 11–12
Verify and explain
Use a decisive fixture, changed-context check and concise final account.
Chapter contents
Build the first model · Chapters 1–3
1. Freeze the requested window before construction
Trace the decisive branch · Chapters 4–5
Change one premise · Chapters 6–8
6. Recheck detachment after construction
Handle limits and failures · Chapters 9–10
Verify and explain · Chapters 11–12
CHAPTER 1 OF 12 · Build the first model
1. Freeze the requested window before construction
The short answer is that slice reads the current source length and converts start and end against that length before it asks a constructor for the result. Chapter 1 focuses on freeze the requested window before construction. Begin with the source’s initial and current byte lengths, start and end conversions, planned new length, species constructor, destination slots and capacity, source detachment state, copied count and untouched destination tail. Writing those facts first prevents a familiar label or final console line from replacing the operation that actually decides the result.
Worked example. Begin with bytes [10,20,30,40,50,60,70,80], start two and end seven; the planned result length is five. Treat every stated value as part of a controlled teaching fixture. Record the starting state before the call, then record each conversion, lookup, check or state transition in order. Stop the trace when an abrupt completion occurs; later effects are not inferred from what normally would have happened.
A useful first-principles question for freeze the requested window before construction is: what must already be true before this step can run? Use the rule above to separate the input contract from the result. Follow object identity, state and returned value independently. Two branches can print similar data while differing in ownership, timing, brand or future capability.
Now change exactly one premise. Change end to minus one and recompute the clamped final index from the original length. Recalculate the trace from the changed fact rather than editing the old conclusion. Name the earliest event that differs, carry that difference through the remaining steps, and say which observations stay the same because their prerequisites did not change.
The main limit is this: The planned interval does not reserve or lock those source bytes while later user code runs. Keep language semantics separate from processor strategy, host scheduling, browser support, trust policy and the meaning assigned by an application. A focused example can establish the stated mechanism without pretending to settle those broader questions.
Practical evidence check. Log start conversion, end conversion and constructor entry as three distinct events. Capture returned values and thrown error classes, but also preserve the event log that led to them. A test that asserts only the last value can pass even when an earlier conversion, constructor, iterator close, atomic operation or realm boundary was wrong.
A concise final explanation of freeze the requested window before construction should state the starting state, the governing rule, the ordered outcome and one boundary. It should not depend on a screenshot, engine message wording or an unstated timing assumption. That form is short enough for revision and precise enough for a code review or debugging note.
CHAPTER 2 OF 12 · Build the first model
2. Let index conversion run observable code
The short answer is that ToClampedIndex can invoke value conversion before species lookup, so a throwing start or end prevents destination construction. Chapter 2 focuses on let index conversion run observable code. Begin with the source’s initial and current byte lengths, start and end conversions, planned new length, species constructor, destination slots and capacity, source detachment state, copied count and untouched destination tail. Writing those facts first prevents a familiar label or final console line from replacing the operation that actually decides the result.
Worked example. Give start a valueOf that records start-convert and returns two, and end one that records end-convert and returns seven. Treat every stated value as part of a controlled teaching fixture. Record the starting state before the call, then record each conversion, lookup, check or state transition in order. Stop the trace when an abrupt completion occurs; later effects are not inferred from what normally would have happened.
A useful first-principles question for let index conversion run observable code is: what must already be true before this step can run? Use the rule above to separate the input contract from the result. Follow object identity, state and returned value independently. Two branches can print similar data while differing in ownership, timing, brand or future capability.
Now change exactly one premise. Make end conversion throw after start succeeds and mark every construction and copy effect as not reached. Recalculate the trace from the changed fact rather than editing the old conclusion. Name the earliest event that differs, carry that difference through the remaining steps, and say which observations stay the same because their prerequisites did not change.
The main limit is this: A printed numeric argument hides the ordering question that matters when conversion is customized. Keep language semantics separate from processor strategy, host scheduling, browser support, trust policy and the meaning assigned by an application. A focused example can establish the stated mechanism without pretending to settle those broader questions.
Practical evidence check. Assert the conversion log and absence of constructor calls rather than checking only the final error. Capture returned values and thrown error classes, but also preserve the event log that led to them. A test that asserts only the last value can pass even when an earlier conversion, constructor, iterator close, atomic operation or realm boundary was wrong.
A concise final explanation of let index conversion run observable code should state the starting state, the governing rule, the ordered outcome and one boundary. It should not depend on a screenshot, engine message wording or an unstated timing assumption. That form is short enough for revision and precise enough for a code review or debugging note.
CHAPTER 3 OF 12 · Build the first model
3. Resolve the species constructor deliberately
The short answer is that slice uses SpeciesConstructor on the source, normally reaching the source constructor and its Symbol.species value. Chapter 3 focuses on resolve the species constructor deliberately. Begin with the source’s initial and current byte lengths, start and end conversions, planned new length, species constructor, destination slots and capacity, source detachment state, copied count and untouched destination tail. Writing those facts first prevents a familiar label or final console line from replacing the operation that actually decides the result.
Worked example. Subclass ArrayBuffer and let the default species create a derived five-byte destination. Treat every stated value as part of a controlled teaching fixture. Record the starting state before the call, then record each conversion, lookup, check or state transition in order. Stop the trace when an abrupt completion occurs; later effects are not inferred from what normally would have happened.
A useful first-principles question for resolve the species constructor deliberately is: what must already be true before this step can run? Use the rule above to separate the input contract from the result. Follow object identity, state and returned value independently. Two branches can print similar data while differing in ownership, timing, brand or future capability.
Now change exactly one premise. Override Symbol.species to return ArrayBuffer and compare the destination prototype while keeping the copied bytes the same. Recalculate the trace from the changed fact rather than editing the old conclusion. Name the earliest event that differs, carry that difference through the remaining steps, and say which observations stay the same because their prerequisites did not change.
The main limit is this: Species selection changes construction, not the already calculated source window. Keep language semantics separate from processor strategy, host scheduling, browser support, trust policy and the meaning assigned by an application. A focused example can establish the stated mechanism without pretending to settle those broader questions.
Practical evidence check. Record the selected constructor, destination identity and destination internal buffer kind. Capture returned values and thrown error classes, but also preserve the event log that led to them. A test that asserts only the last value can pass even when an earlier conversion, constructor, iterator close, atomic operation or realm boundary was wrong.
A concise final explanation of resolve the species constructor deliberately should state the starting state, the governing rule, the ordered outcome and one boundary. It should not depend on a screenshot, engine message wording or an unstated timing assumption. That form is short enough for revision and precise enough for a code review or debugging note.
CHAPTER 4 OF 12 · Trace the decisive branch
4. Validate the destination as an ordinary ArrayBuffer
The short answer is that the constructed result must carry ArrayBuffer data slots, must not be shared or detached, and must not be the source itself. Chapter 4 focuses on validate the destination as an ordinary arraybuffer. Begin with the source’s initial and current byte lengths, start and end conversions, planned new length, species constructor, destination slots and capacity, source detachment state, copied count and untouched destination tail. Writing those facts first prevents a familiar label or final console line from replacing the operation that actually decides the result.
Worked example. Return a fresh ordinary five-byte ArrayBuffer and follow the accepted path. Treat every stated value as part of a controlled teaching fixture. Record the starting state before the call, then record each conversion, lookup, check or state transition in order. Stop the trace when an abrupt completion occurs; later effects are not inferred from what normally would have happened.
A useful first-principles question for validate the destination as an ordinary arraybuffer is: what must already be true before this step can run? Use the rule above to separate the input contract from the result. Follow object identity, state and returned value independently. Two branches can print similar data while differing in ownership, timing, brand or future capability.
Now change exactly one premise. Return a SharedArrayBuffer, a plain object and then the original source from separate species constructors. Recalculate the trace from the changed fact rather than editing the old conclusion. Name the earliest event that differs, carry that difference through the remaining steps, and say which observations stay the same because their prerequisites did not change.
The main limit is this: A byteLength-shaped object is not enough, and returning the source cannot turn slice into an in-place operation. Keep language semantics separate from processor strategy, host scheduling, browser support, trust policy and the meaning assigned by an application. A focused example can establish the stated mechanism without pretending to settle those broader questions.
Practical evidence check. Capture the first TypeError boundary for each invalid destination without inventing later copied bytes. Capture returned values and thrown error classes, but also preserve the event log that led to them. A test that asserts only the last value can pass even when an earlier conversion, constructor, iterator close, atomic operation or realm boundary was wrong.
A concise final explanation of validate the destination as an ordinary arraybuffer should state the starting state, the governing rule, the ordered outcome and one boundary. It should not depend on a screenshot, engine message wording or an unstated timing assumption. That form is short enough for revision and precise enough for a code review or debugging note.
The short answer is that the species-created destination may be larger than requested but cannot be shorter than the planned new length. Chapter 5 focuses on require enough destination capacity. Begin with the source’s initial and current byte lengths, start and end conversions, planned new length, species constructor, destination slots and capacity, source detachment state, copied count and untouched destination tail. Writing those facts first prevents a familiar label or final console line from replacing the operation that actually decides the result.
Worked example. For a five-byte plan, return a seven-byte destination and copy into its first five bytes. Treat every stated value as part of a controlled teaching fixture. Record the starting state before the call, then record each conversion, lookup, check or state transition in order. Stop the trace when an abrupt completion occurs; later effects are not inferred from what normally would have happened.
A useful first-principles question for require enough destination capacity is: what must already be true before this step can run? Use the rule above to separate the input contract from the result. Follow object identity, state and returned value independently. Two branches can print similar data while differing in ownership, timing, brand or future capability.
Now change exactly one premise. Return four bytes and observe TypeError before source copying. Recalculate the trace from the changed fact rather than editing the old conclusion. Name the earliest event that differs, carry that difference through the remaining steps, and say which observations stay the same because their prerequisites did not change.
The main limit is this: A larger destination does not expand the source interval or authorize copying extra bytes. Keep language semantics separate from processor strategy, host scheduling, browser support, trust policy and the meaning assigned by an application. A focused example can establish the stated mechanism without pretending to settle those broader questions.
Practical evidence check. Pre-fill a larger destination with 99 and verify which bytes change and which tail bytes remain 99. Capture returned values and thrown error classes, but also preserve the event log that led to them. A test that asserts only the last value can pass even when an earlier conversion, constructor, iterator close, atomic operation or realm boundary was wrong.
A concise final explanation of require enough destination capacity should state the starting state, the governing rule, the ordered outcome and one boundary. It should not depend on a screenshot, engine message wording or an unstated timing assumption. That form is short enough for revision and precise enough for a code review or debugging note.
The short answer is that species construction can detach the source, so slice performs a detached-source check after destination validation. Chapter 6 focuses on recheck detachment after construction. Begin with the source’s initial and current byte lengths, start and end conversions, planned new length, species constructor, destination slots and capacity, source detachment state, copied count and untouched destination tail. Writing those facts first prevents a familiar label or final console line from replacing the operation that actually decides the result.
Worked example. Have the species constructor transfer the eight-byte source and then return a five-byte destination. Treat every stated value as part of a controlled teaching fixture. Record the starting state before the call, then record each conversion, lookup, check or state transition in order. Stop the trace when an abrupt completion occurs; later effects are not inferred from what normally would have happened.
A useful first-principles question for recheck detachment after construction is: what must already be true before this step can run? Use the rule above to separate the input contract from the result. Follow object identity, state and returned value independently. Two branches can print similar data while differing in ownership, timing, brand or future capability.
Now change exactly one premise. Remove the transfer side effect and compare the path that reaches bounded copying. Recalculate the trace from the changed fact rather than editing the old conclusion. Name the earliest event that differs, carry that difference through the remaining steps, and say which observations stay the same because their prerequisites did not change.
The main limit is this: The source was valid when slice began, yet a later TypeError is correct because user code changed it. Keep language semantics separate from processor strategy, host scheduling, browser support, trust policy and the meaning assigned by an application. A focused example can establish the stated mechanism without pretending to settle those broader questions.
Practical evidence check. Log detachment inside construction and prove that no source bytes were copied afterwards. Capture returned values and thrown error classes, but also preserve the event log that led to them. A test that asserts only the last value can pass even when an earlier conversion, constructor, iterator close, atomic operation or realm boundary was wrong.
A concise final explanation of recheck detachment after construction should state the starting state, the governing rule, the ordered outcome and one boundary. It should not depend on a screenshot, engine message wording or an unstated timing assumption. That form is short enough for revision and precise enough for a code review or debugging note.
CHAPTER 7 OF 12 · Change one premise
7. Read the current length after a resize side effect
The short answer is that after construction the algorithm reads the source’s current byte length and limits copying to what remains beyond the original first index. Chapter 7 focuses on read the current length after a resize side effect. Begin with the source’s initial and current byte lengths, start and end conversions, planned new length, species constructor, destination slots and capacity, source detachment state, copied count and untouched destination tail. Writing those facts first prevents a familiar label or final console line from replacing the operation that actually decides the result.
Worked example. Plan five bytes from indices two through six, shrink the resizable source from eight to five during construction, and copy only indices two through four. Treat every stated value as part of a controlled teaching fixture. Record the starting state before the call, then record each conversion, lookup, check or state transition in order. Stop the trace when an abrupt completion occurs; later effects are not inferred from what normally would have happened.
A useful first-principles question for read the current length after a resize side effect is: what must already be true before this step can run? Use the rule above to separate the input contract from the result. Follow object identity, state and returned value independently. Two branches can print similar data while differing in ownership, timing, brand or future capability.
Now change exactly one premise. Shrink only to seven and show that all five planned bytes remain available. Recalculate the trace from the changed fact rather than editing the old conclusion. Name the earliest event that differs, carry that difference through the remaining steps, and say which observations stay the same because their prerequisites did not change.
The main limit is this: The destination length stays five even when fewer source bytes survive; uncopied positions retain their initialized destination values. Keep language semantics separate from processor strategy, host scheduling, browser support, trust policy and the meaning assigned by an application. A focused example can establish the stated mechanism without pretending to settle those broader questions.
Practical evidence check. Use distinct source values and a zeroed destination so the bounded prefix and untouched tail are visible. Capture returned values and thrown error classes, but also preserve the event log that led to them. A test that asserts only the last value can pass even when an earlier conversion, constructor, iterator close, atomic operation or realm boundary was wrong.
A concise final explanation of read the current length after a resize side effect should state the starting state, the governing rule, the ordered outcome and one boundary. It should not depend on a screenshot, engine message wording or an unstated timing assumption. That form is short enough for revision and precise enough for a code review or debugging note.
The short answer is that when the current source length is at or before the original first index, maxCount is non-positive and the copy step moves no bytes. Chapter 8 focuses on handle shrinkage past the first index. Begin with the source’s initial and current byte lengths, start and end conversions, planned new length, species constructor, destination slots and capacity, source detachment state, copied count and untouched destination tail. Writing those facts first prevents a familiar label or final console line from replacing the operation that actually decides the result.
Worked example. Plan a slice beginning at four, then shrink the source to three during destination construction. Treat every stated value as part of a controlled teaching fixture. Record the starting state before the call, then record each conversion, lookup, check or state transition in order. Stop the trace when an abrupt completion occurs; later effects are not inferred from what normally would have happened.
A useful first-principles question for handle shrinkage past the first index is: what must already be true before this step can run? Use the rule above to separate the input contract from the result. Follow object identity, state and returned value independently. Two branches can print similar data while differing in ownership, timing, brand or future capability.
Now change exactly one premise. Shrink to exactly four and compare the same zero-copy outcome. Recalculate the trace from the changed fact rather than editing the old conclusion. Name the earliest event that differs, carry that difference through the remaining steps, and say which observations stay the same because their prerequisites did not change.
The main limit is this: Zero copied bytes does not mean the requested new length became zero. Keep language semantics separate from processor strategy, host scheduling, browser support, trust policy and the meaning assigned by an application. A focused example can establish the stated mechanism without pretending to settle those broader questions.
Practical evidence check. Assert destination length, all initialized destination bytes and the still-attached source state. Capture returned values and thrown error classes, but also preserve the event log that led to them. A test that asserts only the last value can pass even when an earlier conversion, constructor, iterator close, atomic operation or realm boundary was wrong.
A concise final explanation of handle shrinkage past the first index should state the starting state, the governing rule, the ordered outcome and one boundary. It should not depend on a screenshot, engine message wording or an unstated timing assumption. That form is short enough for revision and precise enough for a code review or debugging note.
CHAPTER 9 OF 12 · Handle limits and failures
9. Keep growth from widening the planned slice
The short answer is that growing the source during species construction cannot increase newLength because start and end were resolved against the earlier length. Chapter 9 focuses on keep growth from widening the planned slice. Begin with the source’s initial and current byte lengths, start and end conversions, planned new length, species constructor, destination slots and capacity, source detachment state, copied count and untouched destination tail. Writing those facts first prevents a familiar label or final console line from replacing the operation that actually decides the result.
Worked example. Plan indices two through six from an eight-byte source, grow it to twelve in construction and still copy five bytes. Treat every stated value as part of a controlled teaching fixture. Record the starting state before the call, then record each conversion, lookup, check or state transition in order. Stop the trace when an abrupt completion occurs; later effects are not inferred from what normally would have happened.
A useful first-principles question for keep growth from widening the planned slice is: what must already be true before this step can run? Use the rule above to separate the input contract from the result. Follow object identity, state and returned value independently. Two branches can print similar data while differing in ownership, timing, brand or future capability.
Now change exactly one premise. Write distinctive values into the grown tail and prove none enter the result. Recalculate the trace from the changed fact rather than editing the old conclusion. Name the earliest event that differs, carry that difference through the remaining steps, and say which observations stay the same because their prerequisites did not change.
The main limit is this: Current length can reduce the copy count after shrinkage, but later growth does not retroactively enlarge the requested interval. Keep language semantics separate from processor strategy, host scheduling, browser support, trust policy and the meaning assigned by an application. A focused example can establish the stated mechanism without pretending to settle those broader questions.
Practical evidence check. Compare planned length, current length and actual count in one table. Capture returned values and thrown error classes, but also preserve the event log that led to them. A test that asserts only the last value can pass even when an earlier conversion, constructor, iterator close, atomic operation or realm boundary was wrong.
A concise final explanation of keep growth from widening the planned slice should state the starting state, the governing rule, the ordered outcome and one boundary. It should not depend on a screenshot, engine message wording or an unstated timing assumption. That form is short enough for revision and precise enough for a code review or debugging note.
CHAPTER 10 OF 12 · Handle limits and failures
10. Separate slice from transfer and resize
The short answer is that slice returns a different buffer and leaves an attached source; transfer returns a different owner and detaches; resize changes one resizable object. Chapter 10 focuses on separate slice from transfer and resize. Begin with the source’s initial and current byte lengths, start and end conversions, planned new length, species constructor, destination slots and capacity, source detachment state, copied count and untouched destination tail. Writing those facts first prevents a familiar label or final console line from replacing the operation that actually decides the result.
Worked example. Run the three operations from independent eight-byte fixtures and compare identity, source usability and target bytes. Treat every stated value as part of a controlled teaching fixture. Record the starting state before the call, then record each conversion, lookup, check or state transition in order. Stop the trace when an abrupt completion occurs; later effects are not inferred from what normally would have happened.
A useful first-principles question for separate slice from transfer and resize is: what must already be true before this step can run? Use the rule above to separate the input contract from the result. Follow object identity, state and returned value independently. Two branches can print similar data while differing in ownership, timing, brand or future capability.
Now change exactly one premise. Request five bytes in each applicable operation and preserve the ownership columns. Recalculate the trace from the changed fact rather than editing the old conclusion. Name the earliest event that differs, carry that difference through the remaining steps, and say which observations stay the same because their prerequisites did not change.
The main limit is this: Similar byte arrays do not establish similar object state or future capability. Keep language semantics separate from processor strategy, host scheduling, browser support, trust policy and the meaning assigned by an application. A focused example can establish the stated mechanism without pretending to settle those broader questions.
Practical evidence check. Check source.detached, source.byteLength, result identity and result resizability for every branch. Capture returned values and thrown error classes, but also preserve the event log that led to them. A test that asserts only the last value can pass even when an earlier conversion, constructor, iterator close, atomic operation or realm boundary was wrong.
A concise final explanation of separate slice from transfer and resize should state the starting state, the governing rule, the ordered outcome and one boundary. It should not depend on a screenshot, engine message wording or an unstated timing assumption. That form is short enough for revision and precise enough for a code review or debugging note.
The short answer is that a useful ledger records state before species construction and again immediately before copying. Chapter 11 focuses on build a two-time state ledger. Begin with the source’s initial and current byte lengths, start and end conversions, planned new length, species constructor, destination slots and capacity, source detachment state, copied count and untouched destination tail. Writing those facts first prevents a familiar label or final console line from replacing the operation that actually decides the result.
Worked example. List initial length eight, planned first two, planned length five, current length five and copy count three. Treat every stated value as part of a controlled teaching fixture. Record the starting state before the call, then record each conversion, lookup, check or state transition in order. Stop the trace when an abrupt completion occurs; later effects are not inferred from what normally would have happened.
A useful first-principles question for build a two-time state ledger is: what must already be true before this step can run? Use the rule above to separate the input contract from the result. Follow object identity, state and returned value independently. Two branches can print similar data while differing in ownership, timing, brand or future capability.
Now change exactly one premise. Change only the construction side effect to growth and recompute current length and count. Recalculate the trace from the changed fact rather than editing the old conclusion. Name the earliest event that differs, carry that difference through the remaining steps, and say which observations stay the same because their prerequisites did not change.
The main limit is this: One final console print cannot show when the source changed or why only part of the destination was overwritten. Keep language semantics separate from processor strategy, host scheduling, browser support, trust policy and the meaning assigned by an application. A focused example can establish the stated mechanism without pretending to settle those broader questions.
Practical evidence check. Require event order, destination contents and source state as separate assertions. Capture returned values and thrown error classes, but also preserve the event log that led to them. A test that asserts only the last value can pass even when an earlier conversion, constructor, iterator close, atomic operation or realm boundary was wrong.
A concise final explanation of build a two-time state ledger should state the starting state, the governing rule, the ordered outcome and one boundary. It should not depend on a screenshot, engine message wording or an unstated timing assumption. That form is short enough for revision and precise enough for a code review or debugging note.
CHAPTER 12 OF 12 · Verify and explain
12. Explain the revalidation rule without overclaiming
The short answer is that a strong account states the planned window, constructor effects, destination checks, current source state and bounded copy in that order. Chapter 12 focuses on explain the revalidation rule without overclaiming. Begin with the source’s initial and current byte lengths, start and end conversions, planned new length, species constructor, destination slots and capacity, source detachment state, copied count and untouched destination tail. Writing those facts first prevents a familiar label or final console line from replacing the operation that actually decides the result.
Worked example. Report five planned bytes, a shrink to five during construction, three copied bytes and two untouched destination bytes. Treat every stated value as part of a controlled teaching fixture. Record the starting state before the call, then record each conversion, lookup, check or state transition in order. Stop the trace when an abrupt completion occurs; later effects are not inferred from what normally would have happened.
A useful first-principles question for explain the revalidation rule without overclaiming is: what must already be true before this step can run? Use the rule above to separate the input contract from the result. Follow object identity, state and returned value independently. Two branches can print similar data while differing in ownership, timing, brand or future capability.
Now change exactly one premise. Replace shrink with detachment and stop the explanation at the post-construction TypeError. Recalculate the trace from the changed fact rather than editing the old conclusion. Name the earliest event that differs, carry that difference through the remaining steps, and say which observations stay the same because their prerequisites did not change.
The main limit is this: The language algorithm does not promise a particular physical copy strategy or make arbitrary subclass code trustworthy. Keep language semantics separate from processor strategy, host scheduling, browser support, trust policy and the meaning assigned by an application. A focused example can establish the stated mechanism without pretending to settle those broader questions.
Practical evidence check. End with the earliest decisive step and one observation that would falsify the trace. Capture returned values and thrown error classes, but also preserve the event log that led to them. A test that asserts only the last value can pass even when an earlier conversion, constructor, iterator close, atomic operation or realm boundary was wrong.
A concise final explanation of explain the revalidation rule without overclaiming should state the starting state, the governing rule, the ordered outcome and one boundary. It should not depend on a screenshot, engine message wording or an unstated timing assumption. That form is short enough for revision and precise enough for a code review or debugging note.
Contents · Previous chapter · Return to the Websites subject guide
Frequently asked questions
Can a species constructor change the source?
Yes. Constructor lookup and construction can run user code, so slice checks the source again.
Does shrinkage change the destination length?
No. The planned destination length was calculated earlier, although fewer source bytes may be copied.
Can growth add more bytes to the slice?
No. The requested interval was already fixed against the earlier source length.
May the destination be larger than requested?
Yes, if it is a valid ordinary ArrayBuffer with at least the requested length.
Does slice detach the source?
No. Ordinary successful slice leaves the source attached.
Is slice the same as transferring a copied buffer?
No. Copying and ownership transfer have different source-state effects.
Continue through the verified reading routes
Start with the wider system
The Gold Standard of Websites · The Gold Standard of Education | Learning That Transfers into Life · How X Works hub
Compare the closest mechanisms
ArrayBuffer transfer versus copying · ArrayBuffer transfer growth, truncation and detachment · transferToFixedLength versus resizability-preserving transfer · DataView bounds after buffer shrinkage and regrowth
Choose the next lesson by reader job
Use the subject root to move from this focused mechanism to the next verified question. Follow a specialist link when its preconditions match your code; return to the wider hub when the next task belongs to a different system.
Continue through the new companion lessons
Separating Atomics.pause Hints from Waiting on a Shared Condition · Tracing Math.sumPrecise Infinity, NaN and Negative-Zero Outcomes · Separating Error.isError Brand Checks from instanceof Across Realms
Authoritative sources and evidence checks
ECMAScript 2027: ArrayBuffer.prototype.slice · ECMAScript 2027: SpeciesConstructor · ECMAScript 2027: ArrayBuffer objects · ECMAScript 2027: ArrayBuffer transfer
The ECMAScript specification defines the language algorithms. A cited proposal draft is used where it contains the integrated Stage 4 text. Controlled runtime checks can confirm an implementation’s current behaviour, but feature availability and performance still depend on the runtime version and environment.