[VOTE] Scalar Type Hints

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

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. ii) Having the code that I write in userland behave differently depending on how people call it, is also horrible. 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. I realise that the RFC as it stands is your preferred option, but just not accepting feedback during an RFC is not appropriate. I think it's clear that a lot of people want scalar types, so I hope that we can get the implementation right, but this RFC isn't it. cheers Dan On 5 February 2015 at 20:14, Andrea Faulds <ajf@ajf.me> wrote:

On 6 February 2015 at 04:14, Andrea Faulds <ajf@ajf.me> wrote:

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

On Thu, Feb 5, 2015 at 9:14 PM, Andrea Faulds <ajf@ajf.me> wrote:

After much initial reluctance, I've voted in favor of this RFC. I'm a proponent of strict scalar typing. I will not explain the reasons behind this here, because they have been covered extensively in the previous threads and I no longer have the patience for such heavily prejudiced discussions. As such this mail is really an explanation why I am voting for an RFC defaulting to weak types, despite my misgivings with such a typing scheme. A primary appeal of this RFC is that the "strict_types" mode not only influences userland function calls, but also calls to internal functions. I really appreciate the symmetry behind this - a plain strict scalar typing proposal would only cover userland calls, while this also enforces proper type usage with internal ones. This seems very reasonable, as the same arguments in favor of strict scalar types for userland functions apply nearly identically to internal functions as well. Another advantage of this approach is that there are fewer interoperability issues between libraries using strict typing internally and external code not making use of it. A pure strict scalar typing proposal would likely cause severe integration issues between code using scalar types and code not using them at all and as such using relatively unpredictable data types. This issue will not be entirely alleviated by this proposal (primarily due to the lack of generic or semi-generic types), but it will be much more limited and libraries should be able to safely use the strict typing mode without alienating users. Lastly, I would like to talk about cognitive overhead. This RFC uses a per-file typing mode declaration and there may be concerns about having to mentally adjust to different modes being used in different files of a project. While I think this is an important concern, there are two ameliorating factors: a) It is very likely that libraries using strict scalar types will use them in the entire project rather than having a mix of different modes in different files. Similarly applications will likely also either be fully strictly typed or have clearly separated front- and backend components where only the latter uses strict scalar types. b) Within one file, this RFC actually removes mental overhead, because type declarations will behave identically for userland and internal functions. You won't have to deal with some functions being liberal and some being strict. Thanks, Nikita

Hi Andrea,

I realise how much effort you put into making scalar type hinting possible in PHP and I applaud you for that. Being a proponent of strict scalar type hinting I also understand the current RFC tries to find a compromise between both camps. It is probably the best we can come up with right now given we want to fullfill the following set of requirements: - Strict scalar hinting - Weak scalar hinting - Let the mode be chosen by the caller, not the callee I nevertheless decided voting against it as I am afraid the current RFC would do more long-term harm to the ecosystem than not having scalar type hints. 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. cu, Lars

On Thu, Feb 5, 2015 at 9:14 PM, Andrea Faulds <ajf@ajf.me> wrote:

Hello, 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 Regards Pavel Kouril

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

On Thu, Feb 5, 2015 at 9:14 PM, Andrea Faulds <ajf@ajf.me> wrote:

hi, 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, 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). 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). Thanks for your efforts on such a hard topic and I hope you can eventually succeed where everyone else failed thus far!

Hello internal, Thank you Andrea for this RFC. I voted today. However, I would like to stress that my vote represents the opinion of Hoa's community [1] and fruux [2] (the company behind sabre/dav [3]). I talked to Pierre Joye today and I was mentioning this is something we do since few months already and I had to spread the word here. So yes, my vote does not represent only 1 person but tens. This is something we will continue since we believe that a vote must not represent the opinion of one person. We consider this is an opportunity to fill the gap between internal and PHP's community. And finally, we would like to encourage people with a vote to talk to anybody around them, at their work, at their open-source project, on IRC etc. to reflect the most valuable opinion. Cheers :-). [1] http://hoa-project.net/ [2] https://fruux.com/ [3] http://sabre.io/ On 05/02/15 21:14, Andrea Faulds wrote:

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

Hi, Just to let you know, I've written a post about this RFC on my blog, trying to present what it brings to the table and to explain why I like it: http://blog.pascal-martin.fr/post/in-favor-of-rfc-scalar-type-hints.html Maybe another way of presenting things might help some people here to decide whether or not they think this RFC is helpful. Even if I've published this earlier today, I've written it between Thursday and Friday, so it doesn't really take into account the new ideas (new syntax propositions) that have been posted since. Please note this is *my* personal opinion, and doesn't necessarily reflect the opinion of any organization I am affiliated with. Pascal.

Hey: On Fri, Feb 6, 2015 at 4:14 AM, Andrea Faulds <ajf@ajf.me> wrote:

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

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

Hi, I vote for the scalar type hints in PHP7, with the synonyms throwing error messages (and reserve the names if the RFC does not pass) Grégory Planchat

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

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!