GeezerVison

No hard feeling on this if we hard-deprecate it again soon together with new Buffer (where possible), but wouldn't it be too much distruption if we deprecate it in 7.0, undeprecate it in 7.x, then deprecate it again in 8.0? How are we going to message that? Upd: this is -0.

@ChALkeR I agree that that might be hard, but I think it is obvious that we need to come up with better messaging for this anyway. Whatever version we land a full runtime deprecation in (if we do that), we should make very clear both what we are doing and why we are doing it, in the changelog and over other channels.

@sindresorhus I’d be interested in hearing where your downvote is coming from. As you probably know, a lot of the push towards reverting the runtime deprecation is coming from people maintaining a noticeable share of the ecosystem, so I think it would really be interesting to hear whatever different perspective you may have?

I don't think we should do that. It's a sign of weakness to step back from the deprecation now, and v7 is a "unstable" release line for a reason. Better get the ecosystem in shape for v8, where it really matters.

It's a sign of weakness to step back from the deprecation now

I am not sure what you are getting at? You can see any actual listening to criticism as a sign of weakness if you want to, and I’m not sure why Node core should value appearing “strong” in the first place.

v7 is a "unstable" release line for a reason.

We’re not talking about experimental features here, and imho the main difference between odd and even release lines should be the different lifespan. The “Current” release line was previously called “Stable” for a reason, too, so I wouldn’t exactly jump to calling it “unstable” now. :)

Okay, after reading up on #8169, I think I'll remain neutral here. I initialy thought this deprection was to push people towards the new APIs for security, but that issue clearly shows other intentions.

I initialy thought this deprection was to push people towards the new APIs for security, but that issue clearly shows other intentions.

Well, imho the impression you had is right – no deprecation should happen for any other reason than that one, and I don’t see any other arguments in favour of deprecating that are strong enough justify it (again, that’s my personal view).

@addaleax I am in favour of deprecating APIs that suck, security or not, carefully, with appropriate timeline, I'm just not seeing how "not being an es6 class" really means "sucks", and I think having to type new everywhere makes the API more sucky... its no coincidence the node API (and most nice to use js APIs, AFAICT), try to make the new an implementation detail of a constructor.

The PRs mentioning es6 didn't work very hard to show what kinds of good things would be possible once Buffer is a "proper es6 class" that aren't possible now. The subtle interactions with some js array types that aren't used in the Node.js API anyhow (unlike Buffer) are also not clear. Probably this could be made compelling, but mostly ATM its just a bit mystifying.

@sam-github Exactly, and I think our messaging turned out terrible here. As we discussed in today’s CTC meeting, we’re going to open a separate issue for more long-term focused planning, i.e. if, how, why and when to deprecate what exactly. I’ll do that, and try to provide everyone with information summing up what has happened so far, that just takes a bit of time.

its no coincidence the node API (and most nice to use js APIs, AFAICT), try to make the new an implementation detail of a constructor.

+1, I'm also annoyed when a dependency forces the new onto me. It can also lead to bugs when one does not know about the precedence of the new operator, e.g. new Thing().prop vs (new Thing()).prop, so if the new was the only reason for this change, I'd be in favor of reverting.

Unless we are 100% that we want to actually do a runtime deprecation of Buffer without new in v8 I believe that this should be reverted. Even if we eventually decide to continue on the deprecation path, hopefully with the support of the community, we can add the warning back after giving individuals more time to get things in order. Alternatively if we find a way forward that does not involved deprecatio, then the warning is not going to be needed anyways.

LGTM

+0 on the revert itself, -1 on the messaging. We aren't doing this just because of the disruption, but because the justification for the hard-deprecation wasn't sufficient for it, and also because the plans to deprecate the Buffer constructor entirely in v8.0 might lead to people having to change their code twice.

@seishun I’ve update the commit message/PR content with bits of your comment, does that seem good to you?

@addaleax Still seems a bit off... Could it possibly be "too disruptive" while the justification is sufficient?

How about something like "as the original justification for the runtime-deprecation does not appear to justify the disruption to Node’s existing ecosystem"?

@seishun Yeah that sounds better to me, too.

Unless we are 100% that we want to actually do a runtime deprecation of Buffer without new in v8

I'm pretty sure that the right course of action for 8.0 would be to runtime-deprecate Buffer(arg), both with and without new, for security reasons.

I would ask to give this revert/discussion time at least before the end of the next CTC meeting before landing it.

I would ask to give this revert/discussion time at least before the end of the next CTC meeting before landing it.

@ChALkeR If you’d like to talk about this in today’s/tomorrow’s meeting, I’d recommend announcing that in the meeting issue @ nodejs/CTC#33 (which I might very will have to miss).

My only question about this PR is this: if we (hopefully) decide to land full Buffer(arg) deprecation in 8.0 and do that, would we think that landing this PR was a good step, looking back from where we would be?

If yes — I have no objections. If no — we should have a resolution on the large issue (Buffer(arg)) deprecations first.

/cc @nodejs/ctc

Upd: in fact, tagging as ctc-agenda because of this.

In the last meeting we were converging on clean break > piecemeal deprecation, IIRC?

My only question about this PR is this: if we (hopefully) decide to land full Buffer(arg) deprecation in 8.0 and do that, would we think that landing this PR was a good step, looking back from where we would be?

I would say so. Judging from most of what I’ve been hearing, the deprecation warning as it is right now is not having the desired effect.

For absolute clarity: When @ChALkeR and @addaleax refer to "full Buffer(args) deprecation"/"full runtime deprecation", does that mean removal? Or does that mean returning to the runtime deprecation situation we have now? I've been assuming it meant removal. But I make a lot of bad assumptions...

I interpreted “full Buffer(args) deprecation” as “print a deprecation warning for every call to Buffer(), with or without new and with any argument types”.

@Trott A single runtime deprecation when Buffer(arg… is used the first time, with or without new, if --no-deprecation flag was not set.

Ah! That answers a whole lot of questions I had. Thanks.

Per nodejs/CTC#36, the CTC decision is to revert, so this should probably be landed before the next 7.x patch release.

Appears to be resolution on the narrow issue here so I'm going to remove the ctc-agenda label. Feel free to re-add if this is something we need to talk about at the meeting this week.

Going to go ahead and land now. Thanks!

Actually, running CI first to be safe: https://ci.nodejs.org/job/node-test-pull-request/5007/

Landed in 4fffe32. Thanks!