Re: Request for comments - new PHP feature: return typing

On Wed, Jul 10, 2013 at 8:30 PM, Sara Golemon <pollita@php.net> wrote: >> With regard to any sort of hinting, an issue of 'one of' return types >> would need to be addressed (I hope). >> >> function foo(SomeClass $bar, int $baz) : bool, SomeClass {} >> >> Allowing for a failure (False) or a success (SomeClass). >> >> We (HHVM) deal with failure alternates by way of a "nullable" syntax: > > function foo(SomeClass $bar, int $baz) : ?SomeClass {} > > Means the function returns SomeClass or null. null being the "failure" > case. > > We also do "mixed" for anything (basically, no type hint, but explicitly > stated), and "numeric" for a less aggressive float/int/numeric-string > (though that's more specific to arg types than return types). > > > >> >> I think it would useful to have a Null hint (like C's void I suppose). >> More to do with explicitly saying no return type, rather than saying >> nothing which means an undefined return type. >> >> function foo(SomeClass $bar, scalar $baz) {} /** you can return >> something, but who knows what will happen with it. **/ >> vs >> function foo(SomeClass $bar, scalar $baz) : Null {} /** This method does >> not return anything and to do so would be wrong. **/ >> >> > function foo() : void {} is our syntax. A null return value is an actual > thing (a null thing), whereas no return is more explicit. I know that > return; gets translated into return > null; anyway, but we also look at > the caller side (return_value_used) and warn about "attempt to use value > from a function returning void" like C/C++ do. > > > Another advantage of scalar is the ability to stop scalar only functions >> from receiving objects, arrays, etc.. Currently no way to inhibit that >> without type testing in the function. >> >> We don't currently do "any scalar", though we do have "numeric" >> (as > mentioned above). I agree with you that "scalar" would be a nice meta-type. > > > >> And, if PHP evolves to allow for __toScalar(), then an object can >> represent itself as a scalar for those situations where the scalar type >> hint is required. I think this may be a bit much initially though (unless >> some clever bod has already worked all this out). Being able to cast an >> instance from type A to type B via __autocast_XXXX where XXXX is the >> resultant type ... ha ha ... OK that really is just pushing things. Maybe. >> >> Going off-topic here, but I worry that __toScalar() would collide in a > messy way with __toString() (and other, future __toXXXX() behavior). Not > severely against it, mind you, but I think we (PHP) need to be cautious > about going down that road. > > -Sara > > P.S. - Your reply only went to me, but I assume you wanted to include > internals@ so I put them back in the To: line. Thanks for your input Sara, everything sounds very interesting. In all fairness I haven't looked at HHVM but I from what you described about this particular feature sounds good. Should I conclude that there's enough interest for this feature and move from a gist to a RFC? If so, I would definitely need someone to help out with the implementation. Best regards, Florin ---- Florin Patan https://github.com/dlsniper http://www.linkedin.com/in/florinpatan