Re: Return Type Hinting for Methods RFC

In the interest of providing options for an ability to mark a method as returning null, I have added a new patch here: http://www.willfitch.com/php/nullable.patch This includes a new token "T_NULLABLE". Here are a few examples: // This is allowed private nullable ArrayIterator getIterator() { return null; } // This throws an E_RECOVERABLE_ERROR private ArrayIterator getIterator() { return null; } The token/identifier can certainly change, but I want to provide the most options for the best solution. On Dec 23, 2011, at 6:31 PM, André Rømcke wrote: > 2011/12/23 John Crenshaw <johncrenshaw@priacta.com> > > From: Will Fitch [mailto:will.fitch@gmail.com] > > > > I would like to take this opportunity to query on a consensus: > > > > Would you prefer to allow methods with type hinted return values to return null at will, > > or add a marker noting that it *may* return null? > > > > Example: Return null at will > > > > public ArrayIterator getIterator() > > { > > // something happened, will return null > > return null; > > } > > > > Example: Return only if identified as such > > > > public ArrayIterator? getIterator() > > { > > return null; > > } > > I hate the syntax in the second example (using ?). > > > It looks strange, but easy to get used to. Two examples from C#: > > > public decimal? Grade { get; set; } > > public Nullable<System.DateTime> Time { get; set; } > > > > IMO allowing null should be the default unless specifically disallowed. > > I disagree for the reasons mentioned by for instance Robert. > Type hints should be strict/explicit or not done at all.