On 12/06/2016 20:55, Nikita Popov wrote:
In that it is similar to the RFC on introducing warnings for invalid numeric strings in arithmetic operations. Sure, that one introduces only a notice while this one throws an exception. Most people probably don't share this opinion, but I think there's actually very little difference between the two for a professional codebase, which (obviously ^^) has a zero notice/warning policy. In either case it's something that must be fixed. (This means that the breakage, if defined as "work required for a deployable upgrade", is probably much much higher for the invalid arithmetic RFC, even though the breakage as in "how badly is the code broken if I do nothing" is smaller.)
OK, that at least is a specific line of reasoning. I don't agree with it, but I can respect its logic.
For the record, I disagree because introducing an error changes program flow, whereas introducing a warning does not (except if there is some handler indiscriminately promoting warnings to errors, I guess, but I'm not aware that that is common practice). Even with a "zero notice/warning policy", it is possible to at least test your application without fixing a new warning; with a new error, you have to fix the problem before doing anything else. Or, more likely, you postpone adoption of the new version, which is surely something we wanted to avoid.
c) If you subscribe to defensive programming, the current behavior implies that you should actually be adding an assert(isset($param)) for each parameter to the start of your function, to ensure that your **required** parameters are really passed. WTF? If I can't rely on required parameters being required in this programming language, what can I rely on at all? I'm willing to accept a small degree of BC breakage to get rid of such nonsense.
Unfortunately, this is still the case after this change: any parameter which can currently be omitted will also accept nulls. The only way of marking a parameter mandatory is to give it a type hint. So as the author of a function, this change makes absolutely no difference to your code; if you want a parameter to be mandatory, the solution in 7.1 as in 7.0 is to add a type hint. As the user of a function, it increases the visibility of an existing warning; since you claim any "professional codebase" will have a zero notice/warning policy anyway, this change will make no difference there either.
Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
