Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68093
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 209.85.160.42 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <CAKUjMCWU1AJhYi9GSPAZyU1U3Gh3paKOAw=fDidSeW96OSvUKA@mail.gmail.com>
References: <CAA9esyS0YL=biVS37ix-yBea7RmZXPnhVk_xKjfz6x+gfN5LNw@mail.gmail.com>
	<CAL+t6cF9JTr9e=A15LvhfgN0DaV8_k4SuEDxQ408fNAAx=8Z_A@mail.gmail.com>
	<CAOX1NOfBPTggj6-WA=ArXjw1UvhUbVC=+FjCYvk6Bgp856biFg@mail.gmail.com>
	<CACwt+Je1vS7MkqShM8+FaDJmAoyaTDCWtTSOuOwG4iWUnyvKHA@mail.gmail.com>
	<CAMUwpuRC8WfrR26W+1hVgXDMt28OQXek68w=9YEGs2ueEiOewg@mail.gmail.com>
	<CACwt+JfoZPuTYk0S3stoDdAftcRB1hAspXNQU4EBkVaX2uiStw@mail.gmail.com>
	<CAH-PCH4BMFrjmNXDJXJ96QT9deWTi7P8P8OR-ZGcr6j=VQ5sig@mail.gmail.com>
	<1372258135.2410.22.camel@guybrush>
	<CAA9esyT854FV6PSxR9pTX3AZ05AJhaYchDmHyBb+Fq_r8rz1xA@mail.gmail.com>
	<CAESVnVqZ2MBej6btO8=KJPVTKD5mOQD+Dzqn_zcZb7XqFSo7+A@mail.gmail.com>
	<CAKUjMCWU1AJhYi9GSPAZyU1U3Gh3paKOAw=fDidSeW96OSvUKA@mail.gmail.com>
Date: Wed, 10 Jul 2013 11:30:59 -0700
Message-ID: <CAESVnVry6r-=ttASy=xM_X5g+=TRQ84dB4cZ5PRQ=BQH29-rcA@mail.gmail.com>
To: RQuadling@gmail.com, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b66f9f7a9dbf604e12c7a68
Subject: Re: [PHP-DEV] Request for comments - new PHP feature: return typing
From: pollita@php.net (Sara Golemon)

--047d7b66f9f7a9dbf604e12c7a68
Content-Type: text/plain; charset=ISO-8859-1

> 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.

--047d7b66f9f7a9dbf604e12c7a68--