Re: [RFC] Return Type Declarations

(Apparently only replied to Sebastian while on mobile :) I know this RFC does not address multiple return types on purpose. But supposing it's implemented in its current form, what would be a possible syntax for multiple/mixed return types? Namely for the usual suspects of string|null, array|null, Class|bool, or ClassA|ClassB|bool, etc... Something along those lines. Cheers On Mon, Apr 28, 2014 at 7:16 PM, Larry Garfield <larry@garfieldtech.com> wrote: > On 4/24/14, 10:59 AM, Levi Morrison wrote: >> >> My dear Internals friends, >> >> I have spent the last month drafting an RFC that allows return types: >> https://wiki.php.net/rfc/returntypehinting >> >> Notable items: >> - Differences from past RFCs are summarized in the RFC: >> >> https://wiki.php.net/rfc/returntypehinting#differences_from_past_rfcs >> - The patch includes basic opcache and reflection support. It also has >> phpt tests. >> - Informal performance tests indicate that the patch did not fubar >> performance; if desired a more detailed test can be conducted before >> voting. >> - This RFC does not add, modify, or remove keywords at all; this >> notably >> excludes type-hints for scalars. Supporting scalar type declarations is >> outside the scope of this RFC; if you are interested in supporting scalar >> type declarations please discuss it elsewhere. >> >> As a friendly reminder, everyone on this list is interested in developing >> a >> better PHP and the definitions of 'better' vary from person to person. >> Please be civil and constructive while discussing this RFC. Thank you! >> >> Some thanks, regardless if the RFC is accepted: >> - For providing a patch: Joe Watkins. >> - For helping me iterate on RFC drafts: Bob Wienand, Nikita Popov and >> Anthony Ferrara >> - For previous RFCs on this topic: Felipe Pena and Will Fitch. I >> gleaned >> valuable knowledge from your proposals and the discussion around them. > > > Simple, targeted, focused, I like. I very much like the NULL handling, as > it means as a caller I have to do less work. > > One bit strikes me as odd. In the invalid examples, you have this example: > > function foo(): array { > yield []; > } > > which generates this error: > > Fatal error: Generators may only yield objects, array is not a valid type in > %s on line %d > > Except Generators can totally yield arrays currently: > > function foo() { > yield []; > } > foreach (foo() as $x) print_r($x) . PHP_EOL; > > The above works perfectly on 5.5.10, where I just tested it. > > So what's with that error condition? Clearly from the RFC we can specify > array as a return type, so I don't know why it calls out generators as > specially limited. > > As I write that I suspect it's because generators actually "return" an > interator object, and so the return type of the generator is being > interpreted relative to the construction, not iteration, of the generator. > That seems like a likely source of confusion, as I would, as a developer, > expect to be specifying the type that gets returned from iteration, not from > construction, so that my foreach loop (or similar) can rely on the type > being returned. > > I think this part warrants further consideration. The rest of the RFC I > fully look forward to using. > > As far as the order of keywords in a closure, what order does Hack use? The > rest of the syntax seems based on it, so it seems sensible to follow suit. > (I couldn't find that information from 60 seconds on hacklang.org, but it > may be there.) > > --Larry Garfield > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >