grant DEP0158 to runtime dep

[AugustinMauroy]

Description

It's documented as deprecated since v16. It's should be emit a deprecation warning

REF

https://nodejs.org/docs/latest/api/deprecations.html#DEP0158

[aduh95]

I doubt there's much value to runtime deprecate it, what's the rational for it?

[AugustinMauroy]

In long terme we can remove this method so we simplify apis and risk. If we emit a warning that will teach to user to use the "right" api.
And both api have same perf and are safe.

Benchmarking buffer.slice() vs buffer.subarray() on v25.2.1
Buffer.slice()                                x 7,649 ops/sec (109 runs sampled) v8-never-optimize=true min..max=(125.23us...137.68us)
Buffer.subarray()                             x 7,523 ops/sec (102 runs sampled) v8-never-optimize=true min..max=(126.02us...144.56us)

[aduh95]

both api have same perf and are safe.

So you're suggesting we intentionally break an API that have OK perf and is safe?

[AugustinMauroy]

I'm not talking about the break yet, but I strongly encourage using another API that is not considered deprecated. If both APIs are truly valid, why name one as deprecated

[aduh95]

I strongly encourage using another API that is not considered deprecated

I share that opinion, but having an opinion is not a justification for breaking the ecosystem

If both APIs are truly valid, why name one as deprecated

You can find the reasons in the PR that introduced the deprecation. Have in mind that doc-only deprecation cannot, by definition, break anyone, so it shouldn't be surprising that the bar for runtime-deprecation is higher.

[hainenber]

Would having an accompanying codemod work out for this one? Im just curious.

[AugustinMauroy]

@panva said

Instead of deprecating Buffer.prototype.slice() with the intent to remove it, we should deprecate the current behavior > with the intent to align it with TypedArray.prototype.slice() in a future major version.

Agreed

Is there a path forward we can take towards that goal?

IDK

[panva]

Reposting my blocking review in #60820 (review)

I have concerns about moving DEP0158 to runtime deprecation. The current approach will create a very confusing and messy experience for users, particularly in library ecosystem scenarios.

When users pass Buffer instances to libraries that are written to accept and expect Uint8Array, those libraries may legitimately call .slice() on the input. If we add a runtime deprecation warning for Buffer.prototype.slice(), users will see warnings that appear to originate from the library they're using, even though:

• The library is doing nothing wrong
• The library is correctly using standard TypedArray.prototype.slice() semantics
• The library author has no control over whether users pass Buffer instances

This creates a confusing attribution problem where deprecation warnings will cause library maintainers unnecessary reports and support burden.

Instead of deprecating Buffer.prototype.slice() with the intent to remove it, we should deprecate the current behavior with the intent to align it with TypedArray.prototype.slice() in a future major version.

Is there a path forward we can take towards that goal?

As an aside, once it'd be removed wouldn't TypedArray.prototype.slice() just take its place?