deprecate Deno.Buffer

[ry]

Move to std

[bartlomieju]

This would be a breaking change so should probably be considered for 2.0.

Additionally Deno.readAll and Deno.readAllSync depend on Buffer, but it should be straight-forward to rewrite them not to depend on Buffer.

[kitsonk]

Deprecating it wouldn't, right? Removing it would.

[bartlomieju]

Deprecating it wouldn't, right? Removing it would.

Sure, how would we go about deprecating? Printing something to console when new instance of Buffer is created? I guess it's a good point to consider how we'll be deprecating APIs going forward (IIRC we haven't done this yet)

[lucacasonato]

/** @deprecate Use buffer from https://deno.land/std/io/buffer.ts instead. */

Maybe we could also add a deno lint lint?

[kitsonk]

I would say no... I would say we simply use @deprecated in the JSDoc... that would highlight it in the documentation and would give anyone using an intelligent editor a visual indication. Logging to stderr/stdout is painful for such things and unnecessary in my opinion.

[kitsonk]

👍 for deno lint but ideally deno lint should just parse the JSDoc and warn on any @deprecated use instead of having to maintain a list of APIs.

[lucacasonato]

ideally deno lint should just parse the JSDoc and warn on any @deprecated use instead of having to maintain a list of APIs.

I don't think this isn't possible until deno lint has type information like TS does.

[kitsonk]

@lucacasonato I commented in denoland/deno_lint#623... it is simply tracking symbols across module boundaries, which swc does... it wouldn't work for type only constructs true, but deno doc doesn't have type information and it reads and tracks stuff just fine, right?

[lucacasonato]

Closing in favor of #9795