[VOTE][RFC] Coercive Scalar Type Hints

9 years ago by Anthony Ferrara — view source

unread

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:

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

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

wiki.php.net/rfc/coercive_sth

wiki.php.net/rfc/coercive_sth#vote

Thanks!

Zeev

9 years ago by Zeev Suraski — view source

unread

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:

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

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

wiki.php.net/rfc/coercive_sth

wiki.php.net/rfc/coercive_sth#vote

Thanks!

Zeev

9 years ago by Dan Ackroyd — view source

unread

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

.

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:

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

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

wiki.php.net/rfc/coercive_sth

wiki.php.net/rfc/coercive_sth#vote

Thanks!

Zeev

9 years ago by Anthony Ferrara — view source

unread

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):

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).
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.
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
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.
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

9 years ago by Zeev Suraski — view source

unread

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

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).

If you copied the whole paragraph (one more sentence) instead of it out of
context it would be clear that we're not at all downplaying anything. We're
portraying it exactly for what it is, for better or worse.
The fact users would have years to adjust is radically different from if we
broke compatibility overnight, and that's exactly what this paragraph
conveys.

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.

I don't consider Drupal/Magento or WordPress framework code. It's real
world apps, very very similar to other custom-coded real world apps.

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.

It's our position, the position of people very well versed in this area that
have written a JIT compiler that runs blazingly fast with no type hints at
all. It's fine that you have a different opinion. One of us is wrong.

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

This is hardly the exact opposite. It means something we agreed on from the
get go - if you change your code so that the compiler can gain more
insight on what the types are during compile-time (e.g. an explicit cast, or
if we add typed variable declarations) - then sure, there'll be AOT/JIT
gains - but they're absolutely not coming from the difference in type hints.
I still contend that with coercive type hints we can perform the exact same
static analysis, with just differently phrased output such as "it may need
to be converted" rather than "will be rejected". Identical type inference
rules. Identical everything, just slightly modified text.

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.

That's one difference, but the real difference is that the rules are
radically - and the coercive ones are what you'd almost always want to use
in real life, while strict almost never is - which means a lot more explicit
casts. The most popular conversion in PHP - string -> number - just works.
With strict mode, it simply doesn't. Personally, I think that the 'it
won't break until you actually flip it on' stance is weak. When people do
flip it on (and they'd certainly be encouraged to do so by many people, e.g.
your blog post from a few weeks ago) - they're going to see massive breakage
which will in turn require massive explicit casting - resulting in much
worse code than in the coercive type hints case.

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???

Because int is commonly used in boolean context, which cannot be said about
float (if you discount the PHP test suite, that is). This patch tries to
provide real-world value and support real-world use cases - and blocks ones
which are more than likely to be mistakes. The rules are designed to work
in the vast majority of cases and support all the sensible conversions. You
can always use explicit casting or otherwise refactor your code if you do
bump into some edge case - but fact is, you'd bump into a lot less problems
than if you flip on strict.

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...

In terms of behavior that's the only thing that changed, and those were
discussed publicly over a week ago. Guys, this isn't House Of Cards. Let's
stay focused on substance.

Zeev

9 years ago by Zeev Suraski — view source

unread

-----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

9 years ago by Dan Ackroyd — view source

unread

I think that going through a transition period ... that ultimately results
in one, consistent language behavior

This RFC is explicitly saying that there is stuff that will be need to
be changed in the future. Why would anyone upgrade from PHP 5.6 to PHP
70 when there are going to be more changes to the type system?

Everyone would wait until that future version of PHP to upgrade and so
just have to do a single migration, instead of having to do two
migrations?

This is clearly worse than the strict STH RFC; with that people can
write code that will work on 5.x, 7 and 7.x by just not using scalar
type hints.

cheers
Dan

9 years ago by Zeev Suraski — view source

unread

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

I think that going through a transition period ... that ultimately
results in one, consistent language behavior

This RFC is explicitly saying that there is stuff that will be need to be
changed
in the future. Why would anyone upgrade from PHP 5.6 to PHP
70 when there are going to be more changes to the type system?

Because of the huge performance gain? And the many features? And the
ability to gradually prepare for future versions softly, like virtually all
of our deprecated functionality lifecycle works?

This is clearly worse than the strict STH RFC; with that people can write
code
that will work on 5.x, 7 and 7.x by just not using scalar type hints.

That's exactly the same here too. Code that works on 7 will work on 5 - 7
will be more restrictive than 5, but not vice versa, so anything that works
on 7, works fine on 5. And you get the benefit of weeding out issues and
make your code better for both versions by checking it on 7.

Zeev

9 years ago by Derick Rethans — view source

unread

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:

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

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?

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

cheers,
Derick

9 years ago by Florian Margaine — view source

unread

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:

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

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

9 years ago by Zeev Suraski — view source

unread

-----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

9 years ago by Benoit Schildnecht — view source

unread

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:

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

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

wiki.php.net/rfc/coercive_sth

wiki.php.net/rfc/coercive_sth#vote

Thanks!

Zeev

9 years ago by eli@eliw.com — view source

unread

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:

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

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 |

9 years ago by Leigh — view source

unread

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

Not sure "designed to be live at the same time" is entirely correct.
It's more of an honour clause to be invoked in the event of
unfortunate circumstances. (With the less honourable option being to
lock in all of the votes and declaring ergo sum victor)

9 years ago by Zeev Suraski — view source

unread

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:

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

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

9 years ago by Dan Ackroyd — view source

unread

Hi Zeev,

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,

People sometimes tell me that they think the PHP-Internals list is a
toxic environment. I usually defend it, saying that it's not that bad,
with people just wanting their view to be considered.

However right now it is toxic, with name calling, people being
contacted off-list with abusive emails and disputes about the rules of
the RFC process during an RFC vote.

Zeev, you have the capability of ending this drama by carrying out the
promise you made to support the scalar_type_hints_v5 RFC if the
Coercive RFC isn't going to pass.

It would be healthier for PHP if we didn't have another 10 days of
toxicity. The scalar_type_hints_v5 is currently passing, and the
Coercive STH RFC is very, very unlikely to pass.

Please will you carry out your promise to retract the Coercive RFC and
support the other RFC a few days early, so that we can move forward
getting PHP 7 ready rather than having this continued toxicity?

cheers
Dan
Ack

9 years ago by Pierre Joye — view source

unread

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:

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

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

Thanks!

Zeev

9 years ago by Ole Markus With — view source

unread

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:

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

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

9 years ago by Zeev Suraski — view source

unread

-----Original Message-----
From: Ole Markus With [mailto:olemarkus@olemarkus.org]
Sent: Thursday, March 12, 2015 10:10 AM
To: Pierre Joye; Zeev Suraski
Cc: PHP internals
Subject: Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints

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:

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

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.

I'm sorry to hear that Ole Markus. I do want to address these concerns:

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

Casting rules aren't touched - it's rules for internal function arguments
that are changed. This has been a key premise of this proposal since the
beginning; Contrary to the 2nd statement, we have a pretty good way of
knowing it won't break things badly out there - running it with real world
apps and our test suite. As the Impact On Real World Applications section
suggests (wiki.php.net/rfc/coercive_sth#changes_to_internal_functions) -
the real world impact is minimal, since the conversion which are blocked are
rarely relied upon in apps. The issues you do get are almost always
legitimate issues - with excellent signal to noise ratio. Users would have
several YEARS to fix these issues before they become errors and not
warnings. Many of the compatibility breakages we've done over the years
(and in 7) had / would have a lot farther reaching impact - often with zero
end-user gain to show for it.
What is being consistently ignored by everyone is the fact that large
projects - with the absence of having a good dynamic option - are likely to
implement strict project-wide, resulting in WAAAY bigger breakage, since the
strict mode does not differentiate between sensible conversions, that have
been relied upon in PHP for the last 20 years ("32" -> 32) and nonsensible
conversions that are for the most part a side effect of implementation ("100
dogs" -> 100).

big changes in the RFC+patch between last discussions and vote.
Should not be allowed, can't veto it so voted no

There have been NO big changes to the proposal - only two tweaks which I
clearly detailed in the Vote email, that have been publicly discussed in
detail on internals@ more than a week ago. There is absolutely no rule in
the voting RFC that requires a long period of time between the last changes
to the RFC and the vote. The mandatory discussion period starts ticking
when the RFC is sent to the list, not when the last changes are made to it.
Anyone claiming otherwise is misleading, as both the text in
wiki.php.net/rfc/voting#discussion_period is clear about when the ticking
starts - and on top of that, I can tell you as the person who introduced the
mandatory discussion period and wrote that text, that resetting the clock on
every change to the RFC was never ever even remotely considered or intended
as a requirement.

Zeev

9 years ago by Lester Caine — view source

unread

There have been NO big changes to the proposal - only two tweaks which I
clearly detailed in the Vote email, that have been publicly discussed in
detail on internals@ more than a week ago.

Zeev ... being realistic I think that the chances of getting another 48
votes in favour are unlikely as are the chances of blocking the other
proposal?

The problem here is that a large number of people want type hinting one
way or another and there is not a strong enough case being made NOT to
bow to that will? So the next problem is perhaps how do we live with a
section of the developer world adding hints to well established
libraries? During the move to PHP5 one could quite happily write code
that continued to work on the majority of PHP4 systems, The move to PHP7
needs the same set of guidelines, so what is currently being championed
which will mean that we have to maintain a PHP5 version of a library
from day one of PHP7 and what do we avoid in order for PHP code still to
run on PHP5?

I still have to be convinced that adding a half baked variable check
does have a major advantage. YOU have demonstrated the various transfer
paths although they lacked the finer detail type checking that already
happens in many code bases such as the range of the number passed.

The bit I am more concerned about is the further dilution of the
docblock annotation as people will adopt type hints in place of the
already existing annotation and again we loose a lot more than we gain
:( Personally I would much prefer that this was picked up properly again
as other RFC's are trying to do, and I feel that answers all of the type
hinting ad other static analysis problems that some people seem to think
are so important. Expansion of the docblock 'standard' will also allow
range of variables to be managed, yet the whole lot can be striped and
ignored once one is out of 'design' phase.

Is the final endpoint target here that like python, PHP will become a
two stage process with compiled versions of user land code?

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

9 years ago by Larry Garfield — view source

unread

There have been NO big changes to the proposal - only two tweaks which I
clearly detailed in the Vote email, that have been publicly discussed in
detail on internals@ more than a week ago.

Zeev ... being realistic I think that the chances of getting another 48
votes in favour are unlikely as are the chances of blocking the other
proposal?

The problem here is that a large number of people want type hinting one
way or another and there is not a strong enough case being made NOT to
bow to that will? So the next problem is perhaps how do we live with a
section of the developer world adding hints to well established
libraries? During the move to PHP5 one could quite happily write code
that continued to work on the majority of PHP4 systems, The move to PHP7
needs the same set of guidelines, so what is currently being championed
which will mean that we have to maintain a PHP5 version of a library
from day one of PHP7 and what do we avoid in order for PHP code still to
run on PHP5?

Code with type hints won't be valid on PHP 5 period, no matter what
approach we take.

Making internal functions pickier about their existing typing doesn't
make writing PHP5-compatible code impossible, it just means you have to
be more careful about weird and probably-buggy cases like
number_format("101 dalmatians"). As Zeev noted, most of the places that
these changes caused an issue are likely existing bugs in the first
place, so the PHP 5 code would become better by being PHP 7-compatible.

The bit I am more concerned about is the further dilution of the
docblock annotation as people will adopt type hints in place of the
already existing annotation and again we loose a lot more than we gain
:( Personally I would much prefer that this was picked up properly again
as other RFC's are trying to do, and I feel that answers all of the type
hinting ad other static analysis problems that some people seem to think
are so important. Expansion of the docblock 'standard' will also allow
range of variables to be managed, yet the whole lot can be striped and
ignored once one is out of 'design' phase.

We don't lose anything by type information moving from a docblock to the
method signature itself, and in fact we gain a great deal as has been
discussed to death in this thread. We already can have whatever type
information you want in docblocks, but that means diddlysquat for the
compiler or runtime. This whole paragraph is a red herring.

Is the final endpoint target here that like python, PHP will become a
two stage process with compiled versions of user land code?

With an opcache built into core and discussion of it moving into the
engine I think that's a given, in practice. That's entirely unrelated to
typing, though.

--Larry Garfield

9 years ago by Lester Caine — view source

unread

There have been NO big changes to the proposal - only two tweaks which I
clearly detailed in the Vote email, that have been publicly discussed in
detail on internals@ more than a week ago.

Zeev ... being realistic I think that the chances of getting another 48
votes in favour are unlikely as are the chances of blocking the other
proposal?

The problem here is that a large number of people want type hinting one
way or another and there is not a strong enough case being made NOT to
bow to that will? So the next problem is perhaps how do we live with a
section of the developer world adding hints to well established
libraries? During the move to PHP5 one could quite happily write code
that continued to work on the majority of PHP4 systems, The move to PHP7
needs the same set of guidelines, so what is currently being championed
which will mean that we have to maintain a PHP5 version of a library
from day one of PHP7 and what do we avoid in order for PHP code still to
run on PHP5?

Code with type hints won't be valid on PHP 5 period, no matter what
approach we take.

Making internal functions pickier about their existing typing doesn't
make writing PHP5-compatible code impossible, it just means you have to
be more careful about weird and probably-buggy cases like
number_format("101 dalmatians"). As Zeev noted, most of the places that
these changes caused an issue are likely existing bugs in the first
place, so the PHP 5 code would become better by being PHP 7-compatible.

If type hinting is NOT used at all, then the code should run on PHP5?
The question is just what does one have to avoid to remain PHP5
compatible, and more important just how does one avoid some third party
use of it getting in the way.

The bit I am more concerned about is the further dilution of the
docblock annotation as people will adopt type hints in place of the
already existing annotation and again we loose a lot more than we gain
:( Personally I would much prefer that this was picked up properly again
as other RFC's are trying to do, and I feel that answers all of the type
hinting ad other static analysis problems that some people seem to think
are so important. Expansion of the docblock 'standard' will also allow
range of variables to be managed, yet the whole lot can be striped and
ignored once one is out of 'design' phase.

We don't lose anything by type information moving from a docblock to the
method signature itself, and in fact we gain a great deal as has been
discussed to death in this thread. We already can have whatever type
information you want in docblocks, but that means diddlysquat for the
compiler or runtime. This whole paragraph is a red herring.

The whole argument about adding type hinting revolves about red
herrings. There is nothing stopping someone using static analysis on
well written and documented PHP5 code today without affecting everybody
elses use of that code.

Is the final endpoint target here that like python, PHP will become a
two stage process with compiled versions of user land code?

With an opcache built into core and discussion of it moving into the
engine I think that's a given, in practice. That's entirely unrelated to
typing, though.

Again much is being made of 'optimizing at compile time' a term which I
simply don't recognise. If one has a script that is running ... it's
running ... and loading it up with more switches is detracting from
performance ... unless there is caching already running?

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

9 years ago by Yasuo Ohgaki — view source

unread

Hi Zeev,

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

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

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

wiki.php.net/rfc/coercive_sth

wiki.php.net/rfc/coercive_sth#vote

Status should be changed to "voting". It's "under discussion" now.

It's not nice to have 2 modes for new feature while we can do it in a
single mode.
BC matters, but cleaner and simpler design would bring more benefits for
both PHP
users and developers. There is enough time to adopt for users.

The default behavior is better with this RFC. Weak mode defined in other
RFC is too
weak to be useful while strict mode seems too restrictive.

e.g.
<?php
function check_num_range(int $num) { if ($num < 0 || $num > 100)
trigger_error('Invalid range'); }
// Somewhere far from function definition.
$num = $GET['num'];
// Somewhere far from $num definition.
check_num_range($num); // Trying to check validity, int and range.
echo 'You have '.$num. ' now <br />'; // But $num could have any string.
//
"check_num_range((int)$num)" wouldn't help also.
?>

If we decide to have even more stricter hint in the future, we may decide
to use "strict"
mode with this RFC. This is more preferable path for PHP being type aware.
IMHO.

For these reasons, I voted "yes" for this, "no" for the other.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

9 years ago by Levi Morrison — view source

unread

Zeev, Dmitry and Francois (and anyone),

I have a question on a specific conversion. There has been a lot of
email about scalar types so I apologize if this is answered somewhere
already.

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.

Am I understanding the current rules correctly? If so can I get more
rationale on this?

Cheers,

Levi Morrison

9 years ago by Rasmus Lerdorf — view source

unread

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

9 years ago by Leigh — view source

unread

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

-Rasmus

"without dataloss" would mean you can go from typeA -> typeB -> typeA'
and typeA === typeA'

9 years ago by Levi Morrison — view source

unread

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?

Ah, I reread part of the RFC. It appears float -> int is unchanged
from current. This only confuses me more, though. If int -> float is
permitted, and float -> int is permitted, I do not understand why
float -> bool is not permitted.

Can someone clarify this?

9 years ago by Levi Morrison — view source

unread

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?

Ah, I reread part of the RFC. It appears float -> int is unchanged
from current. This only confuses me more, though. If int -> float is
permitted, and float -> int is permitted, I do not understand why
float -> bool is not permitted.

Can someone clarify this?

I apologize; my hands didn't keep up with my brain. I meant that if
int -> bool is permitted, and float -> int is permitted, then by
transitive property I would expect float -> bool to be permitted.
Can someone clarify why this is not the case? The RFC does not appear
to justify this behavior (that I can find, anyway).

9 years ago by Benoit Schildknecht — view source

unread

Le Wed, 11 Mar 2015 16:10:44 +0100, Zeev Suraski zeev@zend.com a écrit:

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:

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

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

wiki.php.net/rfc/coercive_sth

wiki.php.net/rfc/coercive_sth#vote

Thanks!

Zeev

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

9 years ago by Yasuo Ohgaki — view source

unread

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

[VOTE][RFC] Coercive Scalar Type Hints

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL