Re: Re: [RFC][VOTE] Nullable Types

On 12/05/2016 12:36, Lester Caine wrote:

On 12/05/16 11:21, Davey Shafik wrote:

E.g. the behavior of passing executing with a null value for the argument is something you should be consciously making a decision on, and passing in null explicitly.

I was actually getting the logic wrong... the problem with this proposal is that I HAVE to add the '?' for many of my libraries to continue to work simply because they do handle the null case. So what was a working system is broken by this change.

As I understand it, no existing code will change behaviour under this proposal. It merely adds an extra feature which libraries *can* use. What's more, it's a feature which makes those libraries *less strict*, not more. Existing code: function something(Bar $bar) {} something(new Bar); // OK something(); // Error: Missing required parameter something(null); // Error: Parameter is not of required type function something_else(Bar $bar = null) {} something_else(new Bar); // OK something_else(); // OK something_else(null); // OK None of this behaviour is going to change, no existing code will break. Now let's say the author of the something function decides to use the new nullable type hint: function something(?Bar $bar) {} something(new Bar); // OK something(); // Error: Missing required parameter something(null); // OK None of your code will be calling something(null) yet, because it was previously an error. So you now have an *extra* way of calling the function, but you don't need to change any existing usages. The only breaking change would be if the author of the something_else function decided to make the argument mandatory but nullable, so that "something_else()" would be an error, but "something_else(null)" wouldn't be. But that's just the same as if they made the argument completely mandatory - it's a breaking change in the library, not something the language change has caused to happen. Regards, -- Rowan Collins [IMSoP]