Re: [PHP-DEV] [RFC] Change the precedence of the concatenation operator

[Levi Morrison]

On Sun, Apr 28, 2019 at 7:45 PM Stanislav Malyshev  wrote:
>
> Hi!
>
> > Nikita, impressive leg work; thanks. It validates Bob's intuition from the
> > RFC ("... these occurrences are quite rare as it almost always is an error
> > in the current form, rendering the impact minimal.")
>
> If the impact is minimal, why do it at all? So, at the cost of BC break
> and breaking old code (which is most definitely not in composer packages
> and likely isn't publicly accessible) we maybe fix 5 bugs. Does this
> justify a BC break? I don't think so. I really wish we'd stop trying to
> add a thousand small incompatibilities between PHP 7 and PHP 8.

I wish we could stop having this conversation on this list over and
over. A certain level of backwards compatibility is essential, but
beyond that you limit the future by the mistakes of the past. In a
language like PHP a lot of mistakes were made, which greatly limits
the future. Every time I try to add a feature which ought not to break
anything I discover some horror in our language. Fixing bugs are often
just as bad.

Now, back to this particular BC break: it doesn't really enable a lot
of future things, so here I can understand the resistance. Personally,
I am slightly in favor of it. It seems like the precedence of
concatenation ought to be lower than most other operators, because it
doesn't make sense to use those operators on the result of the
concatenation. This has occasionally caused small bugs in our code,
and would prefer to fix it long-term.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Issuing CVEs for PHP

[Stanislav Malyshev]

Hi!

I have set up PHP as CNA (CVE Identifiers authority) with MITRE. That
means that we will be assigning our own CVEs from now on. The process in
broad strokes works like this:

1. We request a block of numbers
2. When we have security bug, we use one of the numbers in the block
3. We create CVE descriptions and commit them to the cvelist repo

Much more detailed documentation on how it is done is here:
https://wiki.php.net/cve

So far I am the only one who is registered to commit CVE descriptions to
MITRE upstream repo, but if somebody wants to do it too, I'm sure it can
be arranged.
Note that you can assign CVE to a bug not yet fixed or published in the
open. Please use this capability responsibly and keep the tracking in
https://wiki.php.net/cve . If you are not familiar with the process or
don't want to bother, just put "needed" as CVE number and it will be
taken care of. Please not enter the bug details into the public repo
before the fix is released.

If you have any questions about this, please ask me.
-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Change the precedence of the concatenation operator

[Stanislav Malyshev]

Hi!

> Nikita, impressive leg work; thanks. It validates Bob's intuition from the
> RFC ("... these occurrences are quite rare as it almost always is an error
> in the current form, rendering the impact minimal.")

If the impact is minimal, why do it at all? So, at the cost of BC break
and breaking old code (which is most definitely not in composer packages
and likely isn't publicly accessible) we maybe fix 5 bugs. Does this
justify a BC break? I don't think so. I really wish we'd stop trying to
add a thousand small incompatibilities between PHP 7 and PHP 8.

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Don't silence chr function arguments error

[Sara Golemon]

On Sun, Apr 28, 2019 at 6:05 PM Gabriel Caruso 
wrote:

> Currently, if you pass an argument that is not an integer, it will simply
> return an empty string: https://3v4l.org/FF2nA.


Not entirely accurate. It outputs a one-character string (the null byte).


> In case you pass more than
> 1 argument, it will complain about "Wrong number of arguments":
> https://3v4l.org/Yrr43.
>
>


> The proposal of https://github.com/php/php-src/pull/4080 is to relly these
> checks to ZPP, making the first argument mandatory to an integer, and make
> the error message for extra arguments consistent with the rest of the core
> functions, e.g. "Warning: chr() expects parameter 1 to be int, string
> given".
>
> I'm actually perfectly in favor of raising a proper warning here.  I
noticed the odd behavior when I was porting this function to HHVM and IIRC
I raised a discussion about it and the bottom line was "Let's not do this
because X", and I couldn't possibly tell you what X was. :(
The thread is out there somewhere though.


> The idea is to merge in PHP-7.4, but if there's a consensus that this
> should go into PHP 8 only, so it is :)
>
> Technically a BC break, so 8.0 would be the preferred branch IMO.

-Sara

[PHP-DEV] Don't silence chr function arguments error

[Gabriel Caruso]

Hello Internals.

I'd like to discuss a small change, but that demands a discussion, for a
function in PHP's Core: https://php.net/chr .

Currently, if you pass an argument that is not an integer, it will simply
return an empty string: https://3v4l.org/FF2nA. In case you pass more than
1 argument, it will complain about "Wrong number of arguments":
https://3v4l.org/Yrr43.

The proposal of https://github.com/php/php-src/pull/4080 is to relly these
checks to ZPP, making the first argument mandatory to an integer, and make
the error message for extra arguments consistent with the rest of the core
functions, e.g. "Warning: chr() expects parameter 1 to be int, string
given".

The idea is to merge in PHP-7.4, but if there's a consensus that this
should go into PHP 8 only, so it is :)

Best,

-- Gabriel Caruso

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

[Peter Kokot]

Hello,

On Wed, 10 Apr 2019 at 12:44, G. P. B.  wrote:
>
> Hello Internals,
>
> As there have been no further comments the voting for my RFC [1] to
> deprecate PHP's
> short open tags has started and will run for two (2) weeks.
>
> Best regards
>
> George P. Banyard
>
> [1] https://wiki.php.net/rfc/deprecate_php_short_tags

I want to thank you for this RFC, for your time dedicated to it, for
the actual implementation and everything. You have done everything
correct and also the general idea i.e. removing these legacy tags in
either PHP 8.0 or not was completely correctly pointed out and RFC (at
least according to the current PHP RFC standards) met all the criteria
to get into implementation step. Everyone who is working with PHP
development knows that these short tags are not meant to be used
anymore. Also everything was correctly accepted and the numbers are
correct.

This entire thread is also showing the integrity, intelligence level
of the PHP a bit but one day maybe these legacy leftovers can be
removed, hopefully... Because they really should. So let's not give up
and let's find some normal solution here... RFC and results are quite
clear but maybe Nikita's solution is good enough for all:

- Deprecation warnings in PHP 7.4 (RFC criteria met, people here happy or not)
- PHP 8.0 complete compile error without any option to further use
them anymore (RFC criteria sort of met -!!!, and the reason of
pretending that the legacy apps will work ok on PHP 8.0 also met)
- Actual removal in PHP 9 (because this is then the logical next
step). Removing something like this in PHP 8.1 is not following
semantic versioning at all. Either removal in 8.0 or 9.0.

Cheers and thanks.

--
Peter Kokot

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

[G. P. B.]

On Sun, 28 Apr 2019 at 14:36, Zeev Suraski  wrote:

> As I said numerous times in the past, I'm a firm believer that
>>> controversial RFCs (ones that generate a lot of votes with a substantial
>>> number of opposers) should not pass.  I think this is important when
>>> adding
>>> features - but it's actually a lot more important with deprecations.
>>> When
>>> there's substantial doubt whether a deprecation should go through or not,
>>> there should be no doubt at all - it shouldn't.  This is one of the
>>> clearest cases if not the clearest one we've had to date.
>>>
>>
>> This IMHO applies to the deprecation vote which includes the default
>> change
>>
>
> From my POV it applies to all deprecations, although obviously taking out
> something that's been a basic building block for the last 20+ years is
> probably more of an issue than some 3rd party utility function.
>

 I think this just boils down to what is an acceptable majority, if 2/3 is
not enough then 3/4
but this is another debate altogether.

(and seems that is where people disagree as more people vote for the removal
>> without the deprecation notices which seems to point this is the issue)
>> which in hindsight is a stupid thing to do, but I would have loved that
>> people
>> point out to this specific issue (and the voting structure) during the
>> discussion
>> or even at the beginning of the vote.
>>
>> But basing my self on the vote to remove the short open tags in PHP 8,
>> which
>> cleared with 74% so nearly 3/4 it would need six (6) more "NO" votes
>> without any
>> "YES" votes to be on the 2/3 threshold. Whereas the deprecation votes
>> "only"
>> needs two (2) votes to be on the 2/3 threshold.
>>
>
> That's not how I understood the vote - although honestly, I found the vote
> layout to be a bit weird.
>
> There are are two issues here:
> 1.  Secondary votes only kick in if the primary vote passes.  They're also
> defined as votes where you only need a simple majority for one of the
> options.
> 2.  The two questions are, in fact, one and the same.  Removing a feature
> in a major version requires that we first deprecate it in a mini version,
> in other words - we can't remove something in 8.0 in case it's not first
> deprecated in 7.4.
>
> I admit I found this confusing that the two votes were separate, but the
> way I understood it, is that we may actually deprecate it at 7.4, without
> actually removing it at 8.0, but just keeping it deprecated.  The other way
> around (removing it in 8.0 without first deprecating it in 7.x) is against
> our rules.
>

This was indeed the intention of the voting structure as I wanted to have a
vote to get see
if people were filling to remove it with PHP 8 or leave it longer in the
Engine.

However looking at how some people voted against the deprecation notice but
for the removal
the only meaningfull conclusion I can come up with is that the change of
the default value is
the issue.


> I mean I don't see how we are in unchartered territory, the vote passed,
>> sure
>> with not a huge supra majority but it still passed.
>>
>
> We're in unchartered territory not from a process perspective, but in
> terms of the number of core devs who think it's a really bad idea and the
> fact we're rediculously close to the minimum threshold - for something that
> should really happen with consensus.
>

I can see this but is it really unheard of?


> Moreover going about how Twitter [2] reacted (which isn't necessarely a
>> good
>> metric) it seems a *vast* majority is in favor of this change.
>>
>
> It is, indeed, not a very good or even meaningful metric at all.  The
> folks which are likely to care about this are almost definitely severely
> under-represented both here and on the dev cycles on Twitter.
>

This may well be true but by the same argument I can say that a lot of
people are for this
even tho they didn't express this as much as those against it.


> I can consider it but I am really not keen on it.
>>
>
> I'd sincrerely appreciate it if you did.  I'm not fond of fighting
> windmills, even less so nowadays than in the past - but I really think
> we're making a painful mistake for virtually no gain, and I'm pretty sure
> I'm not alone in thinking that.  Ultimately, nothing in the RFC is new
> compared to what we knew back in 1998 when we decided to have short open
> tags.  There are no new developments that make it more relevant today than
> it was back then - if anything, XML is a lot less important today than it
> was back then (when it was all the rage).  And unlike 1998, the cost
> assocaited with deprecating it now is tremendous.  So even if we can argue
> whether we took the right decision 20 years ago - there's really no new
> grounds to reopen that decision today.
>

The problem is if we don't address it now it will be even more complicated
when
PHP 9 rolls around and then again. I still believe these short tags are a
legacy
oddity that should be removed.

Because what prevent me from then 

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

[Stanislav Malyshev]

Hi!

On 4/28/19 4:52 AM, Benjamin Morel wrote:
>> I don't even mind still having a compile error in PHP 8 when it sees the
> token

I thought one of the arguments for the whole enterprise was to enable
http://www.php.net/unsub.php

Re: [PHP-DEV] Revive Number Format Separator RFC

[Theodore Brown]

On Sat, Apr 27, 2019 at 10:25 PM Stanislav Malyshev  wrote:

> I am not exactly against this feature, but the potential for abuse
> \- like enabling people using integers for things that are not
> integers and should not be stored as integers - worries me now.

Based on the usage analysis Bishop did, people already use integers
for number-like values (e.g. phone and social security numbers) that
can be better represented in other ways.

Perhaps adding the numeric separator feature can actually be an
opportunity to discourage such misuse. We can add a paragraph to the
RFC (and the documentation if it is accepted) that lists examples of
usage that should be avoided.

Ultimately there remains many legitimate uses of large numbers in
code (e.g. scientific constants, unit test values, business logic
thresholds, etc.), and this feature is a simple way to improve their
readability.

I've lost count of the number of times I've been debugging a failing
test and struggling to count the number and position of digits to
make sure I have the right value. This feature would save time when
reading code and indeed prevent a lot of mistakes in the first place.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Adding special case for "eval" in disable_functions INI setting

[Benjamin Eberlei]

Hi everyone,

I have added a patch to introduce a special case for eval when listed in
disable_functions INi setting. From a developer perspective it shouldn't be
necessary to know that eval is not a function but a language construct.
This is why I think this special case is needed rather than adding a new
INI setting.

https://github.com/php/php-src/pull/4084

The patch fixes https://bugs.php.net/bug.php?id=62397

It currently targets 7.4 branch, but the way its implemented I think it
could be merged into the stable branches.

Should I target the PR for 7.1/7.2 or where do the PMs think this should go?

greetings
Benjamin

Re: [PHP-DEV] Retiring PHP's Mirror Program

[Derick Rethans]

On Sat, 27 Apr 2019, Peter Kokot wrote:

> On Mon, 1 Apr 2019 at 16:26, Robert Hickman  wrote:
> >
> > Is there any reason not to use 'php.net' raw without the 'www'?

Yes, it has to with DNS delegation. 

> Additional question: Can we maybe get an insight of a canonical,
> recommended URL which should be used now? Is this www.php.,net or is
> it php.net without www.

https://www.php.net

> Worth noting that now both domains result in 200 OK (previously there
> was a redirection done from php.net to www.php.net):
> curl -IL https://www.php.net
> curl -IL https://php.net

The second one should redirect. I'll have a look next week why it 
doesn't do that.

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io
Like Xdebug? Consider a donation: https://xdebug.org/donate.php,
or become my Patron: https://www.patreon.com/derickr
twitter: @derickr and @xdebug

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

[Thomas Hruska]

On 4/28/2019 4:52 AM, Benjamin Morel wrote:

- it allows tools that automatically convert short open tags to standard
open tags to actually work on PHP 8. Because if I'm not mistaken, if these
tools are based on token_get_all() and "

It's very much possible to use token_get_all() with short open tag 
support disabled and/or removed to convert from short open tags to full 
open tags and, in fact, has already been done.


--
Thomas Hruska
CubicleSoft President

I've got great, time saving software that you will find useful.

http://cubiclesoft.com/

And once you find my software useful:

http://cubiclesoft.com/donate/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

[Zeev Suraski]

On Sun, Apr 28, 2019 at 2:27 PM G. P. B.  wrote:

> On Sun, 28 Apr 2019 at 10:01, Zeev Suraski  wrote:
>
>> On Wed, Apr 24, 2019 at 9:08 PM Reinis Rozitis  wrote:
>>
>> > Also  imo the reason why people write now (and not in the discussion
>> > phase) because for some time in the voting there wasn't the 2/3 majority
>> > for the 7.4 (so no sense to clutter the list) and now in the end only
>> 1-2
>> > votes make the difference.
>> >
>> >
>> At least for me, this definitely was the case.  When I voted, it was
>> nowhere near clearing the 2/3 threshold.
>>
>
> You must have voted on the same day the RFC went to voting.
>

That's definitely possible.  I don't really remember, even though I do
remember there were more than a handful of votes already registered.


> As the next day when I had a chat with Derick for his podcast both votes
> had cleared the 2/3 threshold, not with a big supra-majority but it
> cleared.
> And it was above the threshold for the rest of the voting period everytime
> I
> checked (so mas every two days).
> So are we now going to need to do daily email during the vote to inform
> what is the voting status of our RFC so everyone is in the loop? When
> you can simply just check the RFC page or look at PHP RFC Watch? [1]
>

I think a 24hr reminder going to internals is probably not a bad idea, but
that's beyond the scope of this discussion and it's obviously not your
fault for not sending it, considering one was never required.


> As I said numerous times in the past, I'm a firm believer that
>> controversial RFCs (ones that generate a lot of votes with a substantial
>> number of opposers) should not pass.  I think this is important when
>> adding
>> features - but it's actually a lot more important with deprecations.  When
>> there's substantial doubt whether a deprecation should go through or not,
>> there should be no doubt at all - it shouldn't.  This is one of the
>> clearest cases if not the clearest one we've had to date.
>>
>
> This IMHO applies to the deprecation vote which includes the default change
>

>From my POV it applies to all deprecations, although obviously taking out
something that's been a basic building block for the last 20+ years is
probably more of an issue than some 3rd party utility function.


(and seems that is where people disagree as more people vote for the removal
> without the deprecation notices which seems to point this is the issue)
> which in hindsight is a stupid thing to do, but I would have loved that
> people
> point out to this specific issue (and the voting structure) during the
> discussion
> or even at the beginning of the vote.
>
> But basing my self on the vote to remove the short open tags in PHP 8,
> which
> cleared with 74% so nearly 3/4 it would need six (6) more "NO" votes
> without any
> "YES" votes to be on the 2/3 threshold. Whereas the deprecation votes
> "only"
> needs two (2) votes to be on the 2/3 threshold.
>

That's not how I understood the vote - although honestly, I found the vote
layout to be a bit weird.

There are are two issues here:
1.  Secondary votes only kick in if the primary vote passes.  They're also
defined as votes where you only need a simple majority for one of the
options.
2.  The two questions are, in fact, one and the same.  Removing a feature
in a major version requires that we first deprecate it in a mini version,
in other words - we can't remove something in 8.0 in case it's not first
deprecated in 7.4.

I admit I found this confusing that the two votes were separate, but the
way I understood it, is that we may actually deprecate it at 7.4, without
actually removing it at 8.0, but just keeping it deprecated.  The other way
around (removing it in 8.0 without first deprecating it in 7.x) is against
our rules.


I mean I don't see how we are in unchartered territory, the vote passed,
> sure
> with not a huge supra majority but it still passed.
>

We're in unchartered territory not from a process perspective, but in terms
of the number of core devs who think it's a really bad idea and the fact
we're rediculously close to the minimum threshold - for something that
should really happen with consensus.


> Moreover going about how Twitter [2] reacted (which isn't necessarely a
> good
> metric) it seems a *vast* majority is in favor of this change.
>

It is, indeed, not a very good or even meaningful metric at all.  The folks
which are likely to care about this are almost definitely severely
under-represented both here and on the dev cycles on Twitter.


> I can consider it but I am really not keen on it.
>

I'd sincrerely appreciate it if you did.  I'm not fond of fighting
windmills, even less so nowadays than in the past - but I really think
we're making a painful mistake for virtually no gain, and I'm pretty sure
I'm not alone in thinking that.  Ultimately, nothing in the RFC is new
compared to what we knew back in 1998 when we decided to have short open
tags.  There are no new developments that make it more 

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

[Benjamin Morel]

> I don't even mind still having a compile error in PHP 8 when it sees the
token

I don't have a vote so these are just my 2 cents, but even though I'm all
for removing short open tags entirely, I think that this solution is
excellent for 2 reasons:

- it solves the code leak issue when upgrading blindly from PHP 7 to PHP 8,
and still makes short open tags effectively unusable on PHP 8; it can
therefore make everyone confident that they can then be removed in PHP 9,
as the odds of someone upgrading blindly from PHP 7 to PHP 9 are almost
nonexistent
- it allows tools that automatically convert short open tags to standard
open tags to actually work on PHP 8. Because if I'm not mistaken, if these
tools are based on token_get_all() and "

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

[G. P. B.]

On Sun, 28 Apr 2019 at 10:01, Zeev Suraski  wrote:

> On Wed, Apr 24, 2019 at 9:08 PM Reinis Rozitis  wrote:
>
> > Also  imo the reason why people write now (and not in the discussion
> > phase) because for some time in the voting there wasn't the 2/3 majority
> > for the 7.4 (so no sense to clutter the list) and now in the end only 1-2
> > votes make the difference.
> >
> >
> At least for me, this definitely was the case.  When I voted, it was
> nowhere near clearing the 2/3 threshold.
>

You must have voted on the same day the RFC went to voting.
As the next day when I had a chat with Derick for his podcast both votes
had cleared the 2/3 threshold, not with a big supra-majority but it cleared.
And it was above the threshold for the rest of the voting period everytime I
checked (so mas every two days).
So are we now going to need to do daily email during the vote to inform
what is the voting status of our RFC so everyone is in the loop? When
you can simply just check the RFC page or look at PHP RFC Watch? [1]


> As I said numerous times in the past, I'm a firm believer that
> controversial RFCs (ones that generate a lot of votes with a substantial
> number of opposers) should not pass.  I think this is important when adding
> features - but it's actually a lot more important with deprecations.  When
> there's substantial doubt whether a deprecation should go through or not,
> there should be no doubt at all - it shouldn't.  This is one of the
> clearest cases if not the clearest one we've had to date.
>

This IMHO applies to the deprecation vote which includes the default change
(and seems that is where people disagree as more people vote for the removal
without the deprecation notices which seems to point this is the issue)
which in hindsight is a stupid thing to do, but I would have loved that
people
point out to this specific issue (and the voting structure) during the
discussion
or even at the beginning of the vote.

But basing my self on the vote to remove the short open tags in PHP 8, which
cleared with 74% so nearly 3/4 it would need six (6) more "NO" votes
without any
"YES" votes to be on the 2/3 threshold. Whereas the deprecation votes "only"
needs two (2) votes to be on the 2/3 threshold.
So to my understanding of how the RFC process works there would need to be
at
least three (3) "NO" votes for the deprecation to fail (which I think we
can all agree
how I went about is crap and I'm open to changing how this gets implemented
as
seen on the other ML thread and the PR) and at least seven (7) "NO" votes
for the
removal vote.

Process wise we're in a bit of an unchartered territory here, but I don't
> think we should let the headache involved with figuring out how to reverse
> this decision force us to impose this on our users.  It's better to go
> through this unpleasantry now than deal with the backlash later.
>

I mean I don't see how we are in unchartered territory, the vote passed,
sure
with not a huge supra majority but it still passed.
Moreover going about how Twitter [2] reacted (which isn't necessarely a good
metric) it seems a *vast* majority is in favor of this change.


> George, please consider reopening the vote for an extra week.  That is
> probably the simplest way to move forward from a process standpoint.
>
> Zeev
>

I can consider it but I am really not keen on it.
Because what prevent me from then re-openning the vote again if the vote
then fails?
What happens if the deprecation vote fails but not the removal?
Would this imply changing how it is deprecated which is literally the topic
of the
other thread without any more voting which I'm totally open to how it is
changed?

I don't even mind still having a compile error in PHP 8 when it sees the
token
as I said before I don't really care that much about the timeline.

Best regards

George P. Banyard

[1] https://php-rfc-watch.beberlei.de/
[2] https://twitter.com/nikita_ppv/status/1121040700156579840

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

[Zeev Suraski]

On Wed, Apr 24, 2019 at 9:08 PM Reinis Rozitis  wrote:

> Also  imo the reason why people write now (and not in the discussion
> phase) because for some time in the voting there wasn't the 2/3 majority
> for the 7.4 (so no sense to clutter the list) and now in the end only 1-2
> votes make the difference.
>
>
At least for me, this definitely was the case.  When I voted, it was
nowhere near clearing the 2/3 threshold.

As I said numerous times in the past, I'm a firm believer that
controversial RFCs (ones that generate a lot of votes with a substantial
number of opposers) should not pass.  I think this is important when adding
features - but it's actually a lot more important with deprecations.  When
there's substantial doubt whether a deprecation should go through or not,
there should be no doubt at all - it shouldn't.  This is one of the
clearest cases if not the clearest one we've had to date.

Process wise we're in a bit of an unchartered territory here, but I don't
think we should let the headache involved with figuring out how to reverse
this decision force us to impose this on our users.  It's better to go
through this unpleasantry now than deal with the backlash later.

George, please consider reopening the vote for an extra week.  That is
probably the simplest way to move forward from a process standpoint.

Zeev