> 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.
