[VOTE] Scalar Type Hints View as Markdown

I think the consensus is not so far away.
As far as I understand the rules, it is possible to vote yes and put up a new RFC to remove strict-declare after the voting ends?

Regards
Thomas

Andi Gutmans wrote on 06.02.2015 00:22:

I have to say I’m pretty disappointed at the opening of the vote.
We had a pretty good RFC (thank you) for weak type hinting which was aligned
with the spirit of PHP and everyone was able to rally around it.
This has now been morphed into something very hard to swallow and IMO having
such a declare(…) syntax will be ridiculed by the broader app dev community
until the end of time… But even that syntax aside (it’s only syntax after
all), I think we lost the ability to reach consensus on something so important
to everyone which we haven’t been able to come to agreement on for over 10
years. Finally it was there, in reach and you made a 180 degree turn.

I think it’d be so much easier for us to implement weak type hinting. Have
everyone rally around it. Be happy and then learn and see whether an additional
mechanism is really necessary. We could even add an E_STRICT_TYPES
error_reporting flag to help folks “debug” their code if they so wish to
see if there are any hotspots in their code they may want to take a look at -
again not necessarily an error but maybe a debugging tool.

But net, net - why not just implement the thing everyone can agree on. Have
something really good in the spirit of the PHP Language for PHP 7 and learn how
people leverage that… The reality is that for the majority of the Web
community “1” coming in from HTTP should be accepted as a 1. Period.

I voted “no” but I will vote “yes” for the competing RFC which is 80%
of your RFC. Why are we not given that option??????

Andi

Good evening,

At long last, I’m going to put the RFC to a vote. It’s been long enough -
I don’t think there needs to be, or will be, much further discussion.

I’d like to make sure that everyone voting understands the RFC fully. Please
read the RFC in full: the details are important. And if anyone has any
questions or uncertainties, please ask them before voting. I am very happy to
answer them.

I would urge everyone who wants type hints to vote for this RFC. It is not a
perfect solution, but there can be no perfect solution to this issue. However,
I think it is better than most of the alternatives suggested thus far - see
the rationale section, and previous discussions. Crucially, this RFC would
keep PHP a weakly-typed language, and not force either strict typing, nor weak
typing, on anyone who does not want it. It would allow the addition of type
hints to existing codebases. It would not create a situation where userland
functions are strict yet internal functions are not, because the strict mode
affects both. I’ve tested the implementation myself on my own code, and it
worked well, providing benefits other proposals would not have given (see my
previous post about my experiences).

Voting starts today (2015-02-05) and ends in two weeks’ time (2015-02-19).
In addition to the vote on the main RFC, there is also a vote on the type
aliases issue, and a vote to reserve the type names for future RFCs’ sake if
this RFC fails.

The RFC can be found here, and it contains a voting widget:
https://wiki.php.net/rfc/scalar_type_hints

Thank you for your time.

--
Andrea Faulds
http://ajf.me/

Hi Andi,

I have to say I’m pretty disappointed at the opening of the vote.
We had a pretty good RFC (thank you) for weak type hinting which was aligned with the spirit of PHP and everyone was able to rally around it.

This is far from true. Some people on internals were happy, but only some, and everywhere outside internals I looked, the reception was far more negative.

This has now been morphed into something very hard to swallow and IMO having such a declare(…) syntax will be ridiculed by the broader app dev community until the end of time…

Nobody mocks Perl or JS for use strict.

But even that syntax aside (it’s only syntax after all), I think we lost the ability to reach consensus on something so important to everyone which we haven’t been able to come to agreement on for over 10 years. Finally it was there, in reach and you made a 180 degree turn.

“Consensus” is exaggerated. There was no consensus and to claim there was is to ignore the reality that the PHP community is divided over this issue. I’d love to say that everyone loves weak type hints and if that version had passed we’d all be dancing around happy holding hands, but the reception was not uniformly positive, not even close, and that’s just on internals.

I think it’d be so much easier for us to implement weak type hinting. Have everyone rally around it. Be happy and then learn and see whether an additional mechanism is really necessary.

Who’d be happy? I realise you and Zeev are big fans of weak types, as are many others, but there are also a lot of PHP developers who vehemently disagree with you.

We could even add an E_STRICT_TYPES error_reporting flag to help folks “debug” their code if they so wish to see if there are any hotspots in their code they may want to take a look at - again not necessarily an error but maybe a debugging tool.

Global error handlers affect all code the interpreter runs, which is why we’ve looked down on them in recent times.

But net, net - why not just implement the thing everyone can agree on.

Everyone doesn’t agree on it.

If everyone did agree on it, v0.1 of the RFC would have been the one that went to vote.

Have something really good in the spirit of the PHP Language for PHP 7 and learn how people leverage that… The reality is that for the majority of the Web community “1” coming in from HTTP should be accepted as a 1. Period.

It’s very well and good you claiming that the “majority” agree, but this does not match my experiences. The PHP community is not a single, homogenous entity. It is very difficult to judge.

I voted “no” but I will vote “yes” for the competing RFC which is 80% of your RFC. Why are we not given that option??????

Because I cannot in good conscience push through something in the name of “consensus” which does not even approach it.

--
Andrea Faulds
http://ajf.me/

having such a declare(…) syntax will be ridiculed by the broader app
dev community until the end of time…

I think that's laying it on a bit thick. It's no worse than Python's "from future import", or JS's 'use strict;' (quotes included).

I wish unknown declare directives were ignored, though, because it would make for a great forward-compatibility mechanism. Still, that, like the syntax format, is a decision made many years ago.

I have to say I’m pretty disappointed at the opening of the vote.
We had a pretty good RFC (thank you) for weak type hinting which was aligned with the spirit of PHP and everyone was able to rally around it.
This has now been morphed into something very hard to swallow and IMO having such a declare(…) syntax will be ridiculed by the broader app dev community until the end of time… But even that syntax aside (it’s only syntax after all), I think we lost the ability to reach consensus on something so important to everyone which we haven’t been able to come to agreement on for over 10 years. Finally it was there, in reach and you made a 180 degree turn.

I think it’d be so much easier for us to implement weak type hinting. Have everyone rally around it. Be happy and then learn and see whether an additional mechanism is really necessary. We could even add an E_STRICT_TYPES error_reporting flag to help folks “debug” their code if they so wish to see if there are any hotspots in their code they may want to take a look at - again not necessarily an error but maybe a debugging tool.

But net, net - why not just implement the thing everyone can agree on. Have something really good in the spirit of the PHP Language for PHP 7 and learn how people leverage that… The reality is that for the majority of the Web community “1” coming in from HTTP should be accepted as a 1. Period.

I voted “no” but I will vote “yes” for the competing RFC which is 80% of your RFC. Why are we not given that option??????

I have to agree here while I like the declare option, it should have
been an option as we clearly do not have a consensus during the
discussions (and will never have). Jeopardize the whole because of
that sounds dangerous to me.

Hi Dan,

As much as I want scalar types I'm voting no as:

i) Having this code:

function foo(int $numberOfRightTurns) {
$x = $numberOfRightTurns * 90;
return sin(deg2rad($x))
}

work or blow up depending on a setting at the top of the file is horrible.

From what I’ve seen this is a rather uncommon case.

Also, that code only works for some integer values and not others: the strict version is uniformly broken, the weak version is sometimes broken.

ii) Having the code that I write in userland behave differently
depending on how people call it, is also horrible.

Your code always behaves identically.

Additionally Andrea, I am disappointed that you opened voting without
a option with the 'declare' stuff removed. This is despite myself
having asked you for an vote option for just strict types directly
several times. Other people have asked for a vote option that allows
strict and weak types with a different syntax.

Yes, I realise you and others have asked for such things. I disagree with you there and I don’t think adding strict types to PHP is really a good idea. I’d prefer we have more rather than less consistency between userland and internals.

I realise that the RFC as it stands is your preferred option, but just
not accepting feedback during an RFC is not appropriate.

I have listened to feedback. But listening to feedback and agreeing to any and all suggestions are not the same thing.

Andrea Faulds
http://ajf.me/

+1

At long last, I’m going to put the RFC to a vote. It’s been long enough - I don’t think there needs to be, or will be, much further discussion.

True, and I probably won't respond to any replies to this because we
don't need more noise, but I do want to explain my -1 vote. This is
long and rambling. I apologise. I've posted a formatted version of
this at https://gist.github.com/LawnGnome/354ca07f1799ff88fc35 in case
it's easier to read.

In no particular order, my issues with this RFC:

The declare switch

Adding the cognitive overhead for each file for developers to have to
remember whether they have to cast a value before passing it to a
function or if PHP will automagically do that for them is a bad thing.
Of course, in a small, well compartmentalised file, or a single
developer code base, it wouldn't be a problem. Unfortunately, a lot of
PHP projects aren't that tidy. (Probably most of them, in fact.)

I also disagree with the comparisons that have been drawn on Internals
between declare(strict_types=1), use strict, and from __future__ import foo statements. They're not the same thing at all:

• use strict is ultimately about code quality — am I doing something dumb?
• from __future__ import foo is ultimately about features — yes, I
  want to opt-in for the new shiny.
• declare(strict_types=1) isn't either of those, although it might
  superficially appear so — what it's really about is "I reject your
  philosophy and substitute my own" in terms of typing.

There are structural decisions we can and should let our users make. I
believe this isn't one of them: allowing users to fundamentally change
the typing semantics of a language on a module-by-module level is, in
my opinion, insanity. Languages have to be opinionated about this sort
of issue: if they weren't, there'd only be one programming language
and it would have 800 switches to configure before you could write a
line of code. This sort of decision is the whole point of designing a
language: abdicating it by providing a switch is effectively us
shrugging and saying "sure, whatever, we don't care, so now we'll make
you care".

Strong typing

This ties into the previous point: for scalars, PHP has never been a
strongly typed language. I was once on the train of strict typing
being universally better — if you know that you always have an
integer, you never have to worry about a bad conversion, right? And,
if I was designing a language from scratch, I'd probably still feel
that way.

That language wouldn't be PHP, though. PHP is unapologetically weakly
typed from top to bottom. Designing a feature to break that would be
bad enough. Designing a feature to optionally break that is insidious.
If you care about whether the zval IS_STRING, you can check that
today. Encouraging our users to care goes against the entire
philosophy of the language.

To be clear: yes, we have problems in our type conversion matrix. The
fact that "21 Jump Street" == 21 is an issue (particularly because
it's silent), and we should be talking about that. But strong typing
is not the solution.

Caller versus callee

Making the caller responsible for choosing the type behaviour is a
clever hack. (No pun intended, Facebookers.) I find the idea
intriguing from an academic perspective. Unfortunately, as with the
above point, this isn't consistent with PHP as a language that's
existed for 20 years and had type hinting in its current form for over
10 years. If we accept this, then we only widen the gap between scalar
values and array/object ones: for one set of type declarations, the
behaviour is determined entirely by the callee, and for another, it's
determined by both the callee (via the type hint) and the caller
(whether it will be converted or not).

So what do we do for 7.0?

From where I sit, we had a good solution: it was the 0.1 version of
this RFC. It behaved like PHP should behave, respected PHP's long
standing scalar type handling and conversion rules, but most
importantly, it solved the actual problem scalar type hints are
supposed to solve in the simplest possible way:

Can I guarantee that my function that expects an integer will
really get an integer?

I don't think that adding complexity on top of that helps anyone in
the long run. Yes, we get to tick some extra boxes — "we support
strong typing", "we support weak typing", "we put the user in control"
— but at the cost of having a language that not only supports, but
advertises multiple, inconsistent behaviours, requires users to be
aware of conversion minutiae that they shouldn't have to be mindful
of, and doesn't do anything to solve the actual problem above.

Adam

+1

-----Message d'origine-----
De : adam@adamharvey.name [mailto:adam@adamharvey.name] De la part
de Adam Harvey
Envoyé : vendredi 6 février 2015 02:23
À : Andrea Faulds
Cc : PHP Internals
Objet : Re: [PHP-DEV] [VOTE] Scalar Type Hints

At long last, I’m going to put the RFC to a vote. It’s been long enough - I
don’t think there needs to be, or will be, much further discussion.

True, and I probably won't respond to any replies to this because we
don't need more noise, but I do want to explain my -1 vote. This is
long and rambling. I apologise. I've posted a formatted version of
this at https://gist.github.com/LawnGnome/354ca07f1799ff88fc35 in case
it's easier to read.

In no particular order, my issues with this RFC:

The declare switch

Adding the cognitive overhead for each file for developers to have to
remember whether they have to cast a value before passing it to a
function or if PHP will automagically do that for them is a bad thing.
Of course, in a small, well compartmentalised file, or a single
developer code base, it wouldn't be a problem. Unfortunately, a lot of
PHP projects aren't that tidy. (Probably most of them, in fact.)

I also disagree with the comparisons that have been drawn on Internals
between declare(strict_types=1), use strict, and from __future__ import foo statements. They're not the same thing at all:

• use strict is ultimately about code quality — am I doing something dumb?
• from __future__ import foo is ultimately about features — yes, I
  want to opt-in for the new shiny.
• declare(strict_types=1) isn't either of those, although it might
  superficially appear so — what it's really about is "I reject your
  philosophy and substitute my own" in terms of typing.

There are structural decisions we can and should let our users make. I
believe this isn't one of them: allowing users to fundamentally change
the typing semantics of a language on a module-by-module level is, in
my opinion, insanity. Languages have to be opinionated about this sort
of issue: if they weren't, there'd only be one programming language
and it would have 800 switches to configure before you could write a
line of code. This sort of decision is the whole point of designing a
language: abdicating it by providing a switch is effectively us
shrugging and saying "sure, whatever, we don't care, so now we'll make
you care".

Strong typing

This ties into the previous point: for scalars, PHP has never been a
strongly typed language. I was once on the train of strict typing
being universally better — if you know that you always have an
integer, you never have to worry about a bad conversion, right? And,
if I was designing a language from scratch, I'd probably still feel
that way.

That language wouldn't be PHP, though. PHP is unapologetically weakly
typed from top to bottom. Designing a feature to break that would be
bad enough. Designing a feature to optionally break that is insidious.
If you care about whether the zval IS_STRING, you can check that
today. Encouraging our users to care goes against the entire
philosophy of the language.

To be clear: yes, we have problems in our type conversion matrix. The
fact that "21 Jump Street" == 21 is an issue (particularly because
it's silent), and we should be talking about that. But strong typing
is not the solution.

Caller versus callee

Making the caller responsible for choosing the type behaviour is a
clever hack. (No pun intended, Facebookers.) I find the idea
intriguing from an academic perspective. Unfortunately, as with the
above point, this isn't consistent with PHP as a language that's
existed for 20 years and had type hinting in its current form for over
10 years. If we accept this, then we only widen the gap between scalar
values and array/object ones: for one set of type declarations, the
behaviour is determined entirely by the callee, and for another, it's
determined by both the callee (via the type hint) and the caller
(whether it will be converted or not).

So what do we do for 7.0?

From where I sit, we had a good solution: it was the 0.1 version of
this RFC. It behaved like PHP should behave, respected PHP's long
standing scalar type handling and conversion rules, but most
importantly, it solved the actual problem scalar type hints are
supposed to solve in the simplest possible way:

Can I guarantee that my function that expects an integer will

really get an integer?

I don't think that adding complexity on top of that helps anyone in
the long run. Yes, we get to tick some extra boxes — "we support
strong typing", "we support weak typing", "we put the user in control"
— but at the cost of having a language that not only supports, but
advertises multiple, inconsistent behaviours, requires users to be
aware of conversion minutiae that they shouldn't have to be mindful
of, and doesn't do anything to solve the actual problem above.

Adam

Am 06.02.2015 um 21:22 schrieb Nikita Popov:

After much initial reluctance, I've voted in favor of this RFC.

Thank you Nikita for this decision. I would really like to have any kind
of scalar type hints introduced into PHP. I think most want this, but do
not agree if and how type conversion should happen. I urge all people
who can vote to consider if they can imagine a compromise that satisfies
all parties better and if there will ever be scalar type hints in the
near future if this vote fails. I am concerned the answers are probably
not and no. So please vote in a way that we can have scalar type hints
in the near future.

Thanks to all of you for participating in this discussion and making PHP
a better language!
Dennis

After much initial reluctance, I've voted in favor of this RFC.

After reading your email, Nikita, I deleted my vote (it was no before).
I will review the RFC again, with your arguments (and others) in mind
and maybe I'll come to a different conclusion.

Hi Lars,

My main concern is that the declare statement is
basically a better behaviour changing ini setting and PHPs history is
paved with those. I very much hope for scalar type hinting,
especially a strict variant but this is not what we should merge.

Maybe it's just me, but I didn't quite understand the point you are
making here. Are you saying that declares are more or less like ini
settings?

Cheers

Matteo Beccati

Development & Consulting - http://www.beccati.com/

Hi Pavel,

Good evening,

At long last, I’m going to put the RFC to a vote. It’s been long enough - I don’t think there needs to be, or will be, much further discussion.

I just realized it now (I brought it up in a different manner when
there was discussion about the RFC), but I didn't notice there was a
totally false statement about it in the RFC itself. You probably
should fix it. I'm speaking about the "Strict type checking, which is
used by many popular programming languages, particularly ones which
are statically-typed, such as Java, C#, Haskell, or Facebook's Hack.
It is also used for non-scalar parameter type hints in PHP. With this
approach, an argument is only accepted if its type is exactly the same
as the parameter." paragraph.

This is NOT true (at least for C# and Java), as you can read here in
the documentations of respecitve languages so you should not compare
the strict version of the typing implemented in PHP with other
strongly typed languages, because the PHP's "strict" is stricter than
strongly static typed languages. I really hope noone voted with the
thought that the strict typing acts as it does in Java and C#.

https://msdn.microsoft.com/en-us/library/y5b434w4.aspx
http://docs.oracle.com/javase/specs/jls/se7/html/jls-5.html#jls-5.1.2

I don’t think it’s unfair. There’s a limited set of permitted conversions in some strictly-typed languages, but it’s still strictly-typed.

Thanks.

--
Andrea Faulds
http://ajf.me/

FWIW, while I think strict types - stricter than even strict languages -
don't belong in PHP, this syntax is clearly a step up from declare(), which
was definitely not intended for this purpose.

Zeev

-----Original Message-----
From: Andrea Faulds [mailto:ajf@ajf.me]
Sent: Sunday, February 08, 2015 9:45 PM
To: PHP Internals
Subject: [PHP-DEV] Syntactical change to Scalar Type Hints RFC

Hi,

I’m posting this in a new thread since people might (reasonably) be
ignoring
further responses to the [VOTE] thread.

I’m considering a small change to the Scalar Type Hints RFC, specifically
about syntax. Quite a few people have said they don’t like the declare()
syntax, and it’s easy to see why. It’s rather verbose, it has all the
quirks of
declare() (such as block syntax, not respecting scope), and it’s rather
ugly.

Instead, I’m wondering if the following might be better:

<?php strict

Which would be used like so:

<?php strict

function foobar(): int {
    return 1.0; // error!
}

It’d be a per-file directive, so there’d be zero mixing of modes within
one file,
and you’d avoid the quirks of declare().

It’s also a lot shorter, and it resembles Hack’s syntax:

<?hh // strict

Of course, changing this would mean restarting the vote, but it’s only
been
three days, we’re less than a quarter of the way through voting.

Thoughts? Thanks!

(By the way, I’d appreciate it if this thread didn’t turn into yet another
discussion of how and whether scalar type hints are a bad/good idea. We
already have at least four threads on that subject. I’m just considering a
specific change of syntax.)

--
Andrea Faulds
http://ajf.me/

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

De : Andrea Faulds [mailto:ajf@ajf.me]
Instead, I’m wondering if the following might be better:

<?php strict

Which would be used like so:

<?php strict

function foobar(): int {
    return 1.0; // error!
}

It’d be a per-file directive, so there’d be zero mixing of modes within one
file, and you’d avoid the quirks of declare().

'<?php' is not a 'per-file' directive, as it can appear several times, and is not always the first item in a file.

What would this mean :

Lines of data
...
<?php
php code
?>
Data
<?php strict
Code
...

Would it be strict or not ? or will you interpret the first '<?php' only ? What is the syntax exactly ? Does it make 'strict' a reserved keyword ?

I am sorry but, IMO, it adds ambiguity to declare()'s ugliness.

François

Hi,

I’m posting this in a new thread since people might (reasonably) be ignoring further responses to the [VOTE] thread.

Incidentally, you still used "reply" to create this message, so mail
readers which base threads on headers (e.g. Thunderbird) rather than
subject lines (e.g. GMail) still see it as part of the same thread
(though the subject line change makes it stand out, so I spotted it anyway).

I’m considering a small change to the Scalar Type Hints RFC, specifically about syntax. Quite a few people have said they don’t like the declare() syntax, and it’s easy to see why. It’s rather verbose, it has all the quirks of declare() (such as block syntax, not respecting scope), and it’s rather ugly.

Instead, I’m wondering if the following might be better:

 <?php strict

Which would be used like so:

 <?php strict

 function foobar(): int {
     return 1.0; // error!
 }

It’d be a per-file directive, so there’d be zero mixing of modes within one file, and you’d avoid the quirks of declare().

I find this much, much uglier than declare().

Firstly, it seems to be creating a whole new syntax convention, which
will need its own rules - Can it be preceded by a newline or other
whitespace? Must it be followed by a newline (unlike a normal "<?php"
opening)? Could you enable strict typing in a short tag using "<?=
strict some_function($bar); ?>"?

Secondly, it is less specific than the current proposal - it suggests
that PHP has a generic "strict mode", rather than a "strict
type-checking" mode. Would more "strict" features be added to this mode
later? Or would other keywords be added so that you could, ahem,
"declare" several directives at the top of your block?

Thirdly, it has all the same scoping issues as declare() - you can break
a function up into multiple <?php ... ?> blocks, so it's still possible
to switch it halfway through a declaration, unless extra rules are
added. But it's worse than that, because you could start halfway through
one function, and end halfway through the next:

<?php
function foo() {
// non strict code
?><?php strict
// strict code
}
function bar() {
// still strict
?><?php
// not strict
}

That's impossible with the block version of declare(), because it uses
the same block syntax of { and } as the rest of the code. It might be
possible with the non-block declare(), but it would make more sense to
simply fix that than to introduce a whole new piece of syntax.

If this magic token has the extra effect of causing ?> to be ignored,
that's a fairly major and unrelated feature, which would probably need
its own RFC. If you make the first "<?php" in a file special, that's
still something that was never a consideration before. It's not like
non-block namespace declarations having to be at the top of the file,
because that is still a separate statement, it just has to be the
first statement; whereas this appears to be designed to merge with the
non-statement opening tag.

If you're going to go that far, why not just disallow the block-level
syntax of declare() for this case, if that is the complaint? Or if the
problem is the non-block syntax, why not enforce that a non-block
declare(strict_types) be at the top of the file?

I'm not really sure what problem you're trying to solve, but this to me
looks like a piece of magic that doesn't resemble anything else in PHP.

Regards,

--
Rowan Collins
[IMSoP]

hi,

Hi,

I’m posting this in a new thread since people might (reasonably) be ignoring further responses to the [VOTE] thread.

I’m considering a small change to the Scalar Type Hints RFC, specifically about syntax. Quite a few people have said they don’t like the declare() syntax, and it’s easy to see why. It’s rather verbose, it has all the quirks of declare() (such as block syntax, not respecting scope), and it’s rather ugly.

Instead, I’m wondering if the following might be better:

<?php strict

Which would be used like so:

<?php strict

function foobar(): int {
    return 1.0; // error!
}

It’d be a per-file directive, so there’d be zero mixing of modes within one file, and you’d avoid the quirks of declare().

It’s also a lot shorter, and it resembles Hack’s syntax:

<?hh // strict

Of course, changing this would mean restarting the vote, but it’s only been three days, we’re less than a quarter of the way through voting.

Thoughts? Thanks!

(By the way, I’d appreciate it if this thread didn’t turn into yet another discussion of how and whether scalar type hints are a bad/good idea. We already have at least four threads on that subject. I’m just considering a specific change of syntax.)

I am not sure I like this. It is somehow not very phpish :)

May I ask why you like to do it? Declare works well and only need a
couple of line to make it work like encoding. We may fix as well other
related issues, nothing that does not look fixable.

Cheers,

Pierre

@pierrejoye | http://www.libgd.org

Hi Ferenc,

I've voted no for two reasons:
1, I don't really like the the proposed declare solution, I know that you put much thought and effort with finding a way to make the strict hints opt-in for the caller, but I think it is still not a good compromise: people in favor of strict hints will hate it because it is opt-in from the caller, so they can't use scalar hints to save the boilerplate for argument validation

Hmm. Personally, I don’t think types are really a substitute for argument validation. This doesn’t provide a means to force strict types upon people who don’t want them, sure… but the proposal is designed precisely to prevent that, since I don’t see someone like Zeev (say) wanting to deal with strict types any time soon.

, and other people like me will unlike it because they think that the blockless declare will cause many errors and debugging headache when somebody moves some code between files (or concatenating files as part of their deployment process).

It’s worth noting that I intend to change this to have the “<?php strict” syntax rather than declare(). That’ll have to be a subsequent RFC, as I don’t want to cancel the vote. But it looks like it will pass since all the feedback I’ve got about that so far has been positive.

2, As this is a really polarizing topic I would like if the eventual solution would have wider support from the current php-src regular contributors, and not just pushed through by "force". (And I know that status quo sucks when somebody trying to do innovative stuff, but it is a safe thing to default to).

I’m not sure. There are some people completely opposed to compromise, that can’t be helped. For everyone else, I’m not sure how I feel about contentious votes. If it gets through by a 2/3 majority then presumably it does have significant support, though I worry about lasting impact.

Votes do, at least, provide a way to resolve contentious issues, though.

Thanks for your efforts on such a hard topic and I hope you can eventually succeed where everyone else failed thus far!

Thanks.

--
Andrea Faulds
http://ajf.me/

Hey:

Hey:

Good evening,

At long last, I’m going to put the RFC to a vote. It’s been long enough - I don’t think there needs to be, or will be, much further discussion.

I’d like to make sure that everyone voting understands the RFC fully. Please read the RFC in full: the details are important. And if anyone has any questions or uncertainties, please ask them before voting. I am very happy to answer them.

I would urge everyone who wants type hints to vote for this RFC. It is not a perfect solution, but there can be no perfect solution to this issue. However, I think it is better than most of the alternatives suggested thus far - see the rationale section, and previous discussions. Crucially, this RFC would keep PHP a weakly-typed language, and not force either strict typing, nor weak typing, on anyone who does not want it. It would allow the addition of type hints to existing codebases. It would not create a situation where userland functions are strict yet internal functions are not, because the strict mode affects both. I’ve tested the implementation myself on my own code, and it worked well, providing benefits other proposals would not have given (see my previous post about my experiences).

Voting starts today (2015-02-05) and ends in two weeks’ time (2015-02-19). In addition to the vote on the main RFC, there is also a vote on the type aliases issue, and a vote to reserve the type names for future RFCs’ sake if this RFC fails.

The RFC can be found here, and it contains a voting widget: https://wiki.php.net/rfc/scalar_type_hints

Thank you for your time.

Actually, I was surprised by the progress of voting now...

Seems never have so many users to vote... and bulk of active core
developers are vote against on it.

As a PHP user, I actually don't care about scalar type hinting much..

but I am strongly objecting declare thing...

image of, one line setting care make a project doesn't work...

image of, a larger project, some devers user strict_type, some for
safe doesn't use..

then they have to add declare to every files's head...

it's a nightmare....

I , here, acking you please reconsidering your vote...

<?php

include_one "lib/xxxx.php" // it use strict type

declare(strict_types=0); //damned , restore it.

$a = new B; // autoload, target file use strict type,

declare(strict_types = 0); //damned, restore it.

?>

am I wrong?!

thanks

thanks

--
Andrea Faulds
http://ajf.me/

--

--
Xinchen Hui
@Laruence
http://www.laruence.com/

--
Xinchen Hui
@Laruence
http://www.laruence.com/

We do not have Scalar type hints for years. we code in php for years
without any type check. it's ok. not the primary things.

Look at other dynamic programming language, they may not have the type
check either.

It is ok, and it is fine.

Besides php, there be always other choice.

If you really really need type check now. Take a look HHVM.

I guest hacklang will match your need.

If the PHP keep current states, my code will running till the earth dead.
It works like a ancient rock. What ever , i just care my code work or not.
Appreciate your time.

Netroby

2015-02-16 15:30 GMT+08:00 Pascal MARTIN, AFUP mailing@pascal-martin.fr:

Le 05/02/2015 21:14, Andrea Faulds a écrit :

Voting starts today (2015-02-05) and ends in two weeks’ time (2015-02-19).
In addition to the vote on the main RFC, there is also a vote on the type
aliases issue, and a vote to reserve the type names for future RFCs’ sake if
this RFC fails.

The RFC can be found here, and it contains a voting widget:
https://wiki.php.net/rfc/scalar_type_hints

Hi,

Even if this RFC has been withdrawn, I'm posting this here, hoping it might
prove useful if someone ever tries to revive it.

We've discussed this RFC quite a bit with other members of AFUP, and finally
ended on the +1 side.

Basically, adding type-hinting for scalars goes towards a PHP that is a bit
more "strict" -- which seems like a good thing for us. But, at the same
time, the "weak" mode by default means users can choose to go that way at
their own pace and existing code will keep working, even if calling "strict"
libraries.

The biggest concern we've had is the declare() syntax that feels a bit weird
at first. But that's not enough of a concern for us to be -1 on the RFC as a
whole.

Thanks!

--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/

-----Original Message-----
From: Sebastian B.-Hagensen [mailto:sbj.ml.read@gmail.com]
Sent: Thursday, February 12, 2015 2:11 AM
To: Zeev Suraski
Cc: guilhermeblanco@gmail.com; Rasmus Lerdorf; PHP Internals
Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints

Hi,

2015-02-12 0:08 GMT+01:00 Zeev Suraski zeev@zend.com:

It gives the exact same
value from an API author’s point of view.

But not from an api-consumers point of view.

I didn't claim otherwise. I am claiming that piece is significantly less
important, and that its negative implications outweigh its positive ones.

Without either introducing a
new set of casting/conversion rules or changing existing behavior
(exclusively) 'weak' typehints may be perceived as seriously crippled.
Maybe up to a point where the addition of them wouldn't be justified.

I argued we should tweak the conversion rules.

But unlike the current RFC, v0.1 doesn’t introduce an IMHO alien
concept into a language that considered dynamic typing to be a core
principle since its birth.

It's not. PHP was always open to enforce strict typing in user created
functions.

Being able to do something in custom code - and having language-level syntax
for it are a world a part in terms of condoned language principles. That's
why proponents of this RFC are so much in its favor - and opponents are so
much against. This new syntax would mean explosive growth and official
encouragement for developers to place strict type checking throughout their
code.

Zeev

Hi,

A number (or numeric, or num, or some other name) type hint is something I plan to propose in a future, follow-up RFC.

wouldn't polymorphism (via method overloading) solve the use cases and
be much more useful in the long run than introducing a something
that's not a type into type hints?

PHP already has polymorphism through its dynamic typing. I don’t see method overloading happening any time soon. We have optional parameters and dynamic typing, which all but eliminate the main needs for overloading. We’re a weakly-typed language, so overloading on scalar types might cause unpredictable behaviour (with strict types you’d get an error sometimes, and that’s fine - but calling an entirely different function? Now that’s different.) There’s also the question of how, or if at all, method overloading could interact with our optional parameters and dynamic typing. Finally, overloading can lead to really poor API design: it’s not that uncommon in some languages to see 20 different function definitions with overlapping and non-comprehensive subsets of a method’s behaviour, that are distinguished only by parameter types. It’s one of my least favourite Java/C#/C++ features for that reason.

In response to saying numbers are not a type: well, they are more of an abstract type which integer and float subclass. We already have internal facilities for converting to and from “numbers” alongside integers and floats, I don’t see why we can’t expose this to users.

Thanks.

Andrea Faulds
http://ajf.me/