[VOTE][RFC] Coercive Scalar Type Hints View as Markdown

Anthony,

While I only put in the final changes today, they're identical to what I
said was going to be done on the discussion thread a week+ ago, there was no
further feedback or discussion on these changes. The patch (minus these two
minor changes) has been available for over a week.
I think we've had enough drama with scalar type hints already and it's time
for closure. Let's let the two votes go through and finally get clarity.
If people find big rejects on the tweaked patch which requires substantial
meaningful changes - I'll restart the vote if necessary.

Thanks,

Zeev

-----Original Message-----
From: Anthony Ferrara [mailto:ircmaxell@gmail.com]
Sent: Wednesday, March 11, 2015 5:20 PM
To: Zeev Suraski
Cc: PHP internals
Subject: Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints

Zeev,

Considering that there has not been any discussion of your final proposal
(since the last change), I think putting it to vote prior to having the
ability to
test or discuss is extremely problematic.
Especially considering every time we tried to test the proposal or discuss
it
before you said that you needed to "tweak the rules". Now opening vote
without giving the ability for people to test it or discuss prior to
voting is
extremely bad form.

I strongly suggest that you retract the vote and open discussion on
the
final proposal.

Anthony

The vote on the Coercive Scalar Type Hints is now open for voting.

The latest version of the RFC includes changes discussed on internals@
last
week:

1. Accept string->bool and int->bool conversions (false->bool is not
   supported)

2. Accept leading/trailing spaces in string->number conversions.

wiki.php.net/rfc/coercive_sth

wiki.php.net/rfc/coercive_sth#vote

Thanks!

Zeev

All,

Voting no due to:

i) Having conversion rules be difference in userland to internal functions.

You list 'Single Mode' as a benefit of this RFC, but it's only single
mode if you gloss over this difference. This is a massive cognitive
load, and will be one of those issues that catches users out again and
again. Why on earth should a boolean be convertible to int for some
functions but not others?

What will happen when someone writes code that extends an internal
class and overrides one of the functions, is that the person who is
using that extended class will have to alter their code to use the
extended class in a different way to how they would use the built in
class directly.

For everyone who didn't pick this up in the RFC, it's hidden in the
large chunk of text:
"Unlike user-land scalar type hints, internal functions will accept
nulls as valid scalars."

ii) The subtle BC breaks.

false -> int # No more conversion from bool
true -> string # No more conversion from bool

btw You appear to have only tested this code against barebones
frameworks. These are often written far more cleanly than actual
applications so I don't think the report of 'very limited' BC breaks
is accurate.

iii) Having conversion work, except when they don't. People who want
weak type hints want weak type hints - they don't want code that
breaks unexpectedly.

function foo(int $bar){...}

foo(36/$value);
// works when $value = 1, 2, 3, 4 breaks when $value = 5

This is neither weak nor strict type - this is a horrible hybrid that
would only catch people out.

But finally, the fact that a significant part of the RFC is talking
about how the behaviour will need to be cleaned up in a future RFC,
but at the same time that some of the problems will be left for five
years show that this isn't a sensible RFC to vote for, even for the
people who just want weak types

cheers
Dan

In addition, I'm voting no for the following reasons (in addition to Dan's):

1. It downplays the BC breaks. It says:

   Given the change to the acceptable values into a wide range of
   internal functions, this RFC is likely to result in a substantial
   number of newly introduced E_DEPRECATED warnings in internal function
   invocations, although those can be easily suppressed

   So BC breaks are fine, as long as they are easily suppressed.
   This is madness, as they won't be able to be suppressed in 8 (when
   they will be turned into hard breaks).

2. It judges the BC breaks based on skeleton applications (Drupal 7's
   stock home page, Drupal 7's stock admin interface, Magento's home
   page, Wordpress's home page, ZF2's skeleton app, Symfony's ACME app).
   It doesn't bring up unit tests (which Symfony was shown to have many
   failures). It doesn't show running on non-framework code. It doesn't
   show the average Wordpress/Drupal module for example.

3. It contains massive misinformation.

   It is our position that there is no difference at all between
   strict and coercive typing in terms of potential future AOT/JIT
   development - none at all.

   And

   It is the position of several Strict STH proponents that Strict
   STH can help static analysis in certain cases. For the same reasons
   mentioned above about JIT, we don't believe that is the case -
   although it's possible that Strict Typing may be able to help static
   analysis in certain edge cases. However, it is our belief that even if
   that is true, Static Analyzers need to be designed for Languages,
   rather than Languages being designed for Static Analyzers.

   Yet the JavaScript community is discovering the exact opposite,
   and is looking into a extremely similar dual-mode:
   https://developers.google.com/v8/experiments

4. It makes claims against the dual mode
   RFC that apply to this
   RFC. For example:

   Too strict may lead to too lax. In the Dual Mode RFC, when in
   Strict mode, in many cases, functions would reject values that,
   semantically, are acceptable. For example, a “32” (string) value
   coming back from an integer column in a database table, would not be
   accepted as valid input for a function expecting an integer. Since
   semantically the developer is interested in this argument-passing
   succeeding, they would have the choice of either removing the integer
   STH altogether, or, more likely, explicitly casting the value into an
   integer. This would have the opposite of the desired outcome of strict
   STHs - as explicit casts ($foo = (int) $foo;) always succeed, and
   would happily convert “100 dogs”, “Apples” and even arrays and
   booleans into an integer. Further, since already today, internal
   functions employ coercion rules that are more restrictive than PHP's
   explicit casting, pushing people towards explicit casting will
   actually make things worse in case developers opt for explicit casting
   as they pass values in an internal function call.

   Yet it completely ignores the fact that the identical situation
   appears with the coercive mode RFC. The difference is that with
   Dual-Mode, it's 100% opt-in, where with coercive you're forced to add
   casts.

5. It's full of logical inconsistencies:

   For example, given the following code:

    function foo(bool $abc) {}
   

   These calls work:

    foo(true);
    foo(1);
    foo("test");
   

   While these fail (note they don't fail on 5.x):

    foo(1.0);
    foo(array());
    foo(null);
   

   Why is int accepted for bool, but float rejected???

And that's not even mentioning that this has been put to vote without
having the final version put up for discussion. There were 12
non-voting related changes in the past 28
hours. Some of
them are likely trivial tweaks, but some like allow int/string -> bool conversion are definitely not trivial. I can't actually pull a
diff of the changes due to errors on wiki.php.net, so I can't tell
exactly what was changed...

I'll open another thread about last-minute changes prior to opening
vote, because that has to stop.

Anthony

-----Original Message-----
From: Dan Ackroyd [mailto:danack@basereality.com]
Sent: Wednesday, March 11, 2015 5:53 PM
To: Zeev Suraski
Cc: PHP internals
Subject: Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints

Voting no due to:

i) Having conversion rules be difference in userland to internal
functions.

You list 'Single Mode' as a benefit of this RFC, but it's only single mode
if you
gloss over this difference. This is a massive cognitive load, and will be
one of
those issues that catches users out again and again. Why on earth should a
boolean be convertible to int for some functions but not others?

Bool->int is not allowed across the board. Yes, in 7 internal functions
will emit E_DEPRECATED and userland will reject, but that's a transition
period but the rules are the same for both.

What will happen when someone writes code that extends an internal class
and overrides one of the functions, is that the person who is using that
extended class will have to alter their code to use the extended class in
a
different way to how they would use the built in class directly.

For everyone who didn't pick this up in the RFC, it's hidden in the large
chunk
of text:
"Unlike user-land scalar type hints, internal functions will accept nulls
as valid
scalars."

NULLs are a different case, that's true, but it actually can be resolved in
the future (as is mentioned in the RFC). The key problem with rejecting
NULLs for internal functions in the same way they are for userland is that
this is the standard way you can denote an 'empty' argument. E.g.,
mysqli_connect(null, $username, $password). The problem is that function
implementations rely on coercion of null->string and treat empty strings as
if no argument was supplied. We can easily change it so that these function
explicitly accept NULLs (which is already a supported modifier for ZPP), and
then have explicit handling for NULL as a non-argument. Since it requires
many changes in extension code - that's something that's probably too big
for us to pull off for 7.0, but we can most probably do it for 7.1. Also,
if we accept nullable type hints
(https://wiki.php.net/rfc/nullable_types_rfc) the discrepancy will
practically disappear, as you'd be able to denote an int/null hint in the
very same way you can do it for internal functions.

ii) The subtle BC breaks.

false -> int # No more conversion from bool
true -> string # No more conversion from bool

That's fair; I think the breakage is very limited and worth the gains, but
that's obviously subjective. Clearly, going for a single mode and making it
stricter than what we have today does mean some level of compatibility
breakage by definition - each person should form their opinion on whether
that's worth it or not.

btw You appear to have only tested this code against barebones
frameworks. These are often written far more cleanly than actual
applications so I don't think the report of 'very limited' BC breaks is
accurate.

I don't view Magento, Drupal and Wordpress aren't barebones frameworks.
They're pretty full featured real world apps (that also happen to be
frameworks).

iii) Having conversion work, except when they don't. People who want weak
type hints want weak type hints - they don't want code that breaks
unexpectedly.

function foo(int $bar){...}

foo(36/$value);
// works when $value = 1, 2, 3, 4 breaks when $value = 5

This is neither weak nor strict type - this is a horrible hybrid that
would only
catch people out.

Ultimately it's all about a signal to noise ratio. I think that strict STH
has horrible signal to noise ratio; Weak type hints can easily allow
problematic values to be glossed over and accepted - so there's zero noise,
but also zero signal in case of trouble. This RFC proposes a rule-set that
has very good signal to noise ratio, but of course, there are edge cases
here and there. Personally, I don't feel that all the x div y examples that
were/are commonly brought up in the context of float/int conversions are
very real world, but rather, such edge cases - but here too, each person can
form their opinion about it...

It seems a key thing you don't like about the RFC is that it's transitional
(what you call 'cleanup'). That's fair, but personally, I think that going
through a transition period that on one hand allows both our codebase and
more importantly our users' codebase to evolve - and that ultimately results
in one, consistent language behavior is better than the alternatives (two
modes that will never ever converge).

Either way, thanks for the feedback!

Zeev

Hi,

Derick Rethans derick@php.net writes:

The vote on the Coercive Scalar Type Hints is now open for voting.

The latest version of the RFC includes changes discussed on internals@ last
week:

1. Accept string->bool and int->bool conversions (false->bool is not
   supported)

2. Accept leading/trailing spaces in string->number conversions.

Aren't you supposed to leave it one week between annoucing the latest
RFC with your changes, and the real vote?

I'm reading that the delay is one week after announcing the intent to
vote. Which means that the RFC is in final state before voting, and the
author has announced intention to vote.

I haven't seen the mail announcing this, did I miss it? There were a lot
of mails on internals lately, it may be possible.

If this mail wasn't sent, should the rules be different because there
was a lot of debate on this RFC? Then which other rule should be broken?

Actually, now I read it, it should actually be two weeks ... but then I
guess it was just a tweak on an earlier version:
https://wiki.php.net/rfc/voting#discussion_period

I guess that since there was a lot of discussion, shortening to one week
makes sense.

cheers,
Derick

Cheers,

--
Florian Margaine

-----Original Message-----
From: Derick Rethans [mailto:derick@php.net]
Sent: Wednesday, March 11, 2015 5:57 PM
To: Zeev Suraski
Cc: PHP internals
Subject: Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints

Aren't you supposed to leave it one week between annoucing the latest
RFC
with your changes, and the real vote?

Actually, now I read it, it should actually be two weeks ... but then I
guess it
was just a tweak on an earlier version:
https://wiki.php.net/rfc/voting#discussion_period

That period is between the RFC is "brought up on the list" and when the
voting starts. It doesn't say anywhere that there's a mandatory
discussion period after the last change on the RFC. The mandatory two
week discussion period includes changes to the RFC as a part of the
discussion cycle and doesn't reset on every change. It was announced on
internals almost 3 weeks ago, by one of the authors, as a concrete RFC to
be voted on for PHP 7.0.

Zeev

Benoit ... actually Anthony's original proposal specifically was
designed to be live at the same time as this alternative proposal. And
it's even mentioned in the proposal (stating that it would stay open
until the 13th or when the alternative proposal voting ended - whichever
was later)

So this was all 'as planned' there,
Eli

Hi,

You are making a very huge mistake, IMHO. By having 2 conflicting RFC,
you are taking the risk they both fail. And it won't do any good to the
language.

While you could have either proposed yours after the STH one if it
would have failed, or create a new RFC to make the STH one evolve
if it would have succeeded, you decided to act with precipitation.
Why did you do this ?

I'm kinda sad, upset and anxious.

Regards,

"Zeev Suraski" a écrit dans le message de groupe de discussion :

The vote on the Coercive Scalar Type Hints is now open for voting.

The latest version of the RFC includes changes discussed on
internals@ last
week:

1. Accept string->bool and int->bool conversions (false->bool is not
   supported)

2. Accept leading/trailing spaces in string->number conversions.

wiki.php.net/rfc/coercive_sth

wiki.php.net/rfc/coercive_sth#vote

Thanks!

Zeev

--
| Eli White | http://eliw.com/ | Twitter: EliW |

It was actually Anthony who proposed that I do that. He also proposed that
if they both pass, we'll have a vote to choose between them.

For a lot of people, the dual mode and coercive STH RFCs aren't a zero sum
game. They just want ONE of them to pass to have some sort of scalar type
hinting, and almost don't care what it is. These people should vote in
favor of both RFCs, if they find both of them acceptable.

Rest assured that if I see that they both seem to be failing as we near the
end of the voting time, I'll retract the Coercive STH RFC - and I'll
actually vote in favor of the dual mode RFC, as much as I think it's bad, so
that we have SOME sort of scalar type hinting in 7.

Zeev

-----Original Message-----
From: Benoit Schildnecht [mailto:bensor987@neuf.fr]
Sent: Wednesday, March 11, 2015 8:37 PM
To: internals@lists.php.net
Subject: [PHP-DEV] Re: [VOTE][RFC] Coercive Scalar Type Hints

Hi,

You are making a very huge mistake, IMHO. By having 2 conflicting RFC, you
are taking the risk they both fail. And it won't do any good to the
language.

While you could have either proposed yours after the STH one if it would
have failed, or create a new RFC to make the STH one evolve if it would
have
succeeded, you decided to act with precipitation.
Why did you do this ?

I'm kinda sad, upset and anxious.

Regards,

"Zeev Suraski" a écrit dans le message de groupe de discussion :

The vote on the Coercive Scalar Type Hints is now open for voting.

The latest version of the RFC includes changes discussed on internals@
last
week:

1. Accept string->bool and int->bool conversions (false->bool is not
   supported)

2. Accept leading/trailing spaces in string->number conversions.

wiki.php.net/rfc/coercive_sth

wiki.php.net/rfc/coercive_sth#vote

Thanks!

Zeev

--
To unsubscribe,
visit:
http://www.php.net/unsub.php

The vote on the Coercive Scalar Type Hints is now open for voting.

The latest version of the RFC includes changes discussed on internals@
last
week:

1. Accept string->bool and int->bool conversions (false->bool is not
   supported)

2. Accept leading/trailing spaces in string->number conversions.

wiki.php.net/rfc/coercive_sth

wiki.php.net/rfc/coercive_sth#vote

Voted no for the following reasons:

• change default casting, which has been working since years, consistently
  inconsistent
• due to the previous nature of changes, we have no way to be sure we won't
  break anything badly out there
• big changes in the RFC+patch between last discussions and vote. Should
  not be allowed, can't veto it so voted no

I changed my vote to no for the same reasons.

Cheers,
Ole Markus

It seems that float -> bool is always disallowed. If I am correct
int -> bool is permitted for all values (not just 0 and 1), which
means that floats which can be converted to integers without dataloss
should also be permitted to be booleans. If a specific float can be
converted to an int, and all ints can be converted to booleans, then
the transitive property should hold for that float to a bool.

The problem there is what does "without dataloss" mean? At which precision do you consider there to be no dataloss?

-Rasmus

Hi Benoit,

On Sun, Mar 29, 2015 at 2:49 AM, Benoit Schildknecht bensor987@neuf.fr
wrote:

Why hasn't it closed ? It's way past the 25th.

Vote was closed before the end date. IIRC.
It's "withdrawn" status, I suppose.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net