# Request for comments - new PHP feature: return typing

- Thread: https://externals.io/message/67850
- Original archive: https://news-web.php.net/php.internals/67850
- Started by Florin Patan on 2013-06-26T09:50:52+00:00
- Messages: 35
- Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/67850.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #67850 — Florin Patan — 2013-06-26T09:50:52+00:00

URL: https://externals.io/message/67850#67850

Hello PHP internals,


Currently PHP doesn't support what could be a good feature for code
quality, return typing (or if you prefer to call it: return type
hinting).

Since the procedure says that before any real RFC should be done, the
interest for this topic should be gauged, I've drafted something here:
https://gist.github.com/dlsniper/5863012

The goals for this discussion are:
- gauge the interest in having such a feature in PHP.NEXT
- find weak spots in the draft
- find potential problems with the suggested way of doing the implementation
- determine if the advantages would outweigh the disadvantages and
this should go forward as a RFC

As you can see, the draft doesn't include any patch and since my C
skills are mostly nonexistent, I currently can't provide one
unfortunately. I would however love to do it with proper guidance from
someone that could spare some of his/her time to help me out.

This said, thank you very much for your time, consideration and
feedback on this subject.


Best regards,
Florin
----
Florin Patan
https://github.com/dlsniper
http://www.linkedin.com/in/florinpatan

---

## #67852 — Sherif Ramadan — 2013-06-26T10:08:40+00:00

URL: https://externals.io/message/67850#67852 · In reply to: #67850

> Hello PHP internals,
>
>
> Currently PHP doesn't support what could be a good feature for code
> quality, return typing (or if you prefer to call it: return type
> hinting).
>
> Since the procedure says that before any real RFC should be done, the
> interest for this topic should be gauged, I've drafted something here:
> https://gist.github.com/dlsniper/5863012
>
> The goals for this discussion are:
> - gauge the interest in having such a feature in PHP.NEXT
> - find weak spots in the draft
> - find potential problems with the suggested way of doing the
> implementation
> - determine if the advantages would outweigh the disadvantages and
> this should go forward as a RFC
>
> As you can see, the draft doesn't include any patch and since my C
> skills are mostly nonexistent, I currently can't provide one
> unfortunately. I would however love to do it with proper guidance from
> someone that could spare some of his/her time to help me out.
>
> This said, thank you very much for your time, consideration and
> feedback on this subject.
>
>
> Best regards,
> Florin
> ----
> Florin Patan
> https://github.com/dlsniper
> http://www.linkedin.com/in/florinpatan
>
> --
> 
> 
>
>
PHP really doesn't need function return type declaration since PHP doesn't
even support variable declaration. This would make sense in a language like
C or C++ where the compiler can do static analyses to determine potential
errors before compiling.

Since PHP is a loosely typed dynamic language, however, the fact that a
function can return something of any type is quite liberating and it turns
out that you don't need the static analyses to write better code with PHP,
because most of the errors static analyses helps you with aren't really the
things you are most concerned with. For example consider the following bug:

<?php
function userTimezone($userId, PDO $db) {
    $result = [];
    if (!($stmt = $db->prepare('SELECT `timezone` FROM users WHERE
users.`id` = ?'))) {
        return false;
    }
    if ($stmt->execute([$userId])) {
        $result = $stmt->fetchAll(PDO::FETCH_ASSOC);
    }
    return array_pop($result);
}
?>

If in the above code PDO::prepare returns false (upon failure) for any
reason $stmt will not be of the expected type. In that case the function
returns a boolean false to indicate failure (or it can throw an exception
as well). If the Exception is throw the function's return value is still
implicitly null. However, the return type of the function isn't what we
actually care about here, because it doesn't solve our real problem. The
real problem we care about is the fact that the function failed and
couldn't keep its promise. If we force the function to only return an array
we can't tell the difference between an empty result set or a failure case
unless we strictly stick to exceptions. In none of those cases was the
function's return value type hint helpful.

---

## #67863 — Maxwell — 2013-06-26T12:35:16+00:00

URL: https://externals.io/message/67850#67863 · In reply to: #67852

Sherif,
I have to disagree with you on this in the same way that we have type hints
for input variables on methods, this could also be useful.
Consider an interface with a getter method defined. As it stands now in
php, they're not entirely useful, since you can't define what type of
object your expecting from the implementer. That greatly reduces the
functionality of an interface and this proposal gives solution to that
problem.

Florin,
I think the overall concept is good, I want to see something like this in
the future, but I think this might be the wrong approach. I don't think we
should be hinting primitives. if we're going to have a return type hint on
a method, I would have it match the functionality of the input type hints
for functions we already have, where you can hint at an instance of an
object type, such as Iterator or StdClass, or an array, but not hint
primitives such as int and string, like I currently see in the draft.
Also, you should be aware that your proposed syntax for the return type (
<type> ) is interfering with:
https://wiki.php.net/rfc/protocol_type_hintingand seems unnecessary to
me.




On Wed, Jun 26, 2013 at 5:08 AM, Sherif Ramadan <theanomaly.is@gmail.com>wrote:

> On Wed, Jun 26, 2013 at 5:50 AM, Florin Patan <florinpatan@gmail.com>
> wrote:
>
> > […]
> PHP really doesn't need function return type declaration since PHP doesn't
> even support variable declaration. This would make sense in a language like
> C or C++ where the compiler can do static analyses to determine potential
> errors before compiling.
>
> Since PHP is a loosely typed dynamic language, however, the fact that a
> function can return something of any type is quite liberating and it turns
> out that you don't need the static analyses to write better code with PHP,
> because most of the errors static analyses helps you with aren't really the
> things you are most concerned with. For example consider the following bug:
>
> <?php
> function userTimezone($userId, PDO $db) {
>     $result = [];
>     if (!($stmt = $db->prepare('SELECT `timezone` FROM users WHERE
> users.`id` = ?'))) {
>         return false;
>     }
>     if ($stmt->execute([$userId])) {
>         $result = $stmt->fetchAll(PDO::FETCH_ASSOC);
>     }
>     return array_pop($result);
> }
> ?>
>
> If in the above code PDO::prepare returns false (upon failure) for any
> reason $stmt will not be of the expected type. In that case the function
> returns a boolean false to indicate failure (or it can throw an exception
> as well). If the Exception is throw the function's return value is still
> implicitly null. However, the return type of the function isn't what we
> actually care about here, because it doesn't solve our real problem. The
> real problem we care about is the fact that the function failed and
> couldn't keep its promise. If we force the function to only return an array
> we can't tell the difference between an empty result set or a failure case
> unless we strictly stick to exceptions. In none of those cases was the
> function's return value type hint helpful.

---

## #67864 — Patrick ALLAERT — 2013-06-26T12:58:50+00:00

URL: https://externals.io/message/67850#67864 · In reply to: #67863

2013/6/26 Maxwell <Max@maxvandervelde.com>:
> Sherif,
> I have to disagree with you on this in the same way that we have type hints
> for input variables on methods, this could also be useful.
> Consider an interface with a getter method defined. As it stands now in
> php, they're not entirely useful, since you can't define what type of
> object your expecting from the implementer. That greatly reduces the
> functionality of an interface and this proposal gives solution to that
> problem.
>
> Florin,
> I think the overall concept is good, I want to see something like this in
> the future, but I think this might be the wrong approach. I don't think we
> should be hinting primitives. if we're going to have a return type hint on
> a method, I would have it match the functionality of the input type hints
> for functions we already have, where you can hint at an instance of an
> object type, such as Iterator or StdClass, or an array, but not hint
> primitives such as int and string, like I currently see in the draft.
> Also, you should be aware that your proposed syntax for the return type (
> <type> ) is interfering with:
> https://wiki.php.net/rfc/protocol_type_hintingand seems unnecessary to
> me.

Thanks Maxwell, you summarized very well what I was thinking about it.
So +1 from me for the general feature at a first glance, but it should
then be very close to what is possible with input type hinting.

It makes it possible to write interfaces that acts like specifications
and to easier the writing of:

class Foo {
    public function bar($input) {
        $return = Baz::foo($input);
        if (!$return instanceof ReturnType)
            trigger_error("Cannot divide by zero", E_USER_ERROR); //
or throwing some RuntimeException

        return $return;
    }
}

to:

class Foo {
    public function <ReturnType> bar($input) {
        return Baz::foo($input);
    }
}

---

## #67868 — Julien Pauli — 2013-06-26T13:35:47+00:00

URL: https://externals.io/message/67850#67868 · In reply to: #67864

On Wed, Jun 26, 2013 at 2:58 PM, Patrick ALLAERT <patrickallaert@php.net>wrote:

> 2013/6/26 Maxwell <Max@maxvandervelde.com>:
> > […]
> hints
> > […]
> we
> > […]
> on
> > […]
>
> Thanks Maxwell, you summarized very well what I was thinking about it.
> So +1 from me for the general feature at a first glance, but it should
> then be very close to what is possible with input type hinting.
>
> It makes it possible to write interfaces that acts like specifications
> and to easier the writing of:
>
> class Foo {
>     public function bar($input) {
>         $return = Baz::foo($input);
>         if (!$return instanceof ReturnType)
>             trigger_error("Cannot divide by zero", E_USER_ERROR); //
> or throwing some RuntimeException
>
>         return $return;
>     }
> }
>
> to:
>
> class Foo {
>     public function <ReturnType> bar($input) {
>         return Baz::foo($input);
>     }
> }
>

+1 for the global idea as this would help so much OO programs and framework
based programs.

But what Sherif said proves as well the limits of the idea. PHP is not
strongly typed. So each check, should it be type hinting or return type
hinting, has to be done at runtime , which is bad for performances.

Not talking about the type juggling which could lead the programmer as
shooting himself.

Julien.Pauli

---

## #67869 — Marco Pivetta — 2013-06-26T13:38:59+00:00

URL: https://externals.io/message/67850#67869 · In reply to: #67868

> On Wed, Jun 26, 2013 at 2:58 PM, Patrick ALLAERT <patrickallaert@php.net
> > […]

But what Sherif said proves as well the limits of the idea. PHP is not
> strongly typed. So each check, should it be type hinting or return type
> hinting, has to be done at runtime , which is bad for performances.
>
> Not talking about the type juggling which could lead the programmer as
> shooting himself.
>
> Julien.Pauli
>

What about disabling the check in some environments (prod)? It would work
like an assertion I suppose. (Feel free to shoot at me if you think it's a
bad idea)

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

---

## #67871 — Patrick ALLAERT — 2013-06-26T14:21:13+00:00

URL: https://externals.io/message/67850#67871 · In reply to: #67868

2013/6/26 Julien Pauli <jpauli@php.net>:
> But what Sherif said proves as well the limits of the idea. PHP is not
> strongly typed. So each check, should it be type hinting or return type
> hinting, has to be done at runtime , which is bad for performances.

It doesn't mean you have to use it, just that it might be used instead
of implementing a manual check in every function/method callers, or,
alternatively, in the function/method itself.
Being done at runtime by the language will for sure not be worst for
performance than doing it manually in pure PHP.

> Not talking about the type juggling which could lead the programmer as
> shooting himself.

Sure! Hence why *if* this is taken into account, it should really be
done the same way as it is done for input parameter hinting, to not
introduce what we already don't want there.

---

## #67874 — Ferenc Kovacs — 2013-06-26T14:40:56+00:00

URL: https://externals.io/message/67850#67874 · In reply to: #67871

On Wed, Jun 26, 2013 at 4:21 PM, Patrick ALLAERT <patrickallaert@php.net>wrote:

> 2013/6/26 Julien Pauli <jpauli@php.net>:
> > […]
>
> It doesn't mean you have to use it, just that it might be used instead
> of implementing a manual check in every function/method callers, or,
> alternatively, in the function/method itself.
> Being done at runtime by the language will for sure not be worst for
> performance than doing it manually in pure PHP.
>
> > […]
>
> Sure! Hence why *if* this is taken into account, it should really be
> done the same way as it is done for input parameter hinting, to not
> introduce what we already don't want there.
>
>
I think that the return typehints a bit easier topic than the input type
hinting(for scalars), because that affects the caller, while return type
hinting is more contained: you write the function, you put the return
typehint there, if the method tries to return something else, then your
code is at fault.
So even if we would allow return typehints for scalars that would only
affects those functions where the developer opts-in.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

---

## #67875 — Patrick ALLAERT — 2013-06-26T14:43:44+00:00

URL: https://externals.io/message/67850#67875 · In reply to: #67869

2013/6/26 Marco Pivetta <ocramius@gmail.com>:
> What about disabling the check in some environments (prod)? It would work
> like an assertion I suppose. (Feel free to shoot at me if you think it's a
> bad idea)

<shoot>
This is typically something that has always been rejected in the past.
</shoot

---

## #67877 — johannes@schlueters.de — 2013-06-26T14:48:55+00:00

URL: https://externals.io/message/67850#67877 · In reply to: #67874

> > […]
> I think that the return typehints a bit easier topic than the input type
> hinting(for scalars), because that affects the caller, while return type
> hinting is more contained: you write the function, you put the return
> typehint there, if the method tries to return something else, then your
> code is at fault.
> So even if we would allow return typehints for scalars that would only
> affects those functions where the developer opts-in.

So a function author doesn't trust himself and therefore we change the
language syntax?

johannes

---

## #67879 — Florin Patan — 2013-06-26T14:59:02+00:00

URL: https://externals.io/message/67850#67879 · In reply to: #67877

On Wed, Jun 26, 2013 at 4:48 PM, Johannes Schlüter
<johannes@schlueters.de> wrote:
> 
>
> > […]
>
> So a function author doesn't trust himself and therefore we change the
> language syntax?
>
> johannes
>

All,


Thanks for the feedback so far.

I've added the typing for scalars as I thought it would be nice to
have them but if it's easier to start with supporting what we already
have for argument hinting then it would be a great win for the
language nonetheless.

To address the performance concern issues, I think the performance
issues should be very little, like a call to instanceof for example,
but I can't say for sure. Of course benchmarks for the actual
implementation will need to be made and a manual entry should note
that using this feature might have a performance impact if really
needed (as I would imagine in 15000 function calls, something that you
might see in todays frameworks it could have a more visible impact).

@johannes it's not about the author of the function doesn't trust
itself, it's about I'm writing a interface and I expect to receive a
array but someone returns a string or a single value.

That's why I've said that the feature is more about code quality that
new toys for developers. Those who opt-in for using this in interfaces
would guarantee that every implementation of their interface would be
consistent in return type, just like what we have today for arguments,
where you can guarantee that you'll have the type you need in your
method.

If the feedback will be positive for this, as it is right now, I would
also like to start working on a patch for this in 2-3 weeks maybe so
this is a early request for help for anyone that could point me out in
the right direction or champion this patch. I'll make another request
when I'll be ready to start working on the patch.


Best regards.
----
Florin Patan
https://github.com/dlsniper
http://www.linkedin.com/in/florinpatan

---

## #67883 — Florin Patan — 2013-06-26T15:23:58+00:00

URL: https://externals.io/message/67850#67883 · In reply to: #67868

> On Wed, Jun 26, 2013 at 2:58 PM, Patrick ALLAERT <patrickallaert@php.net>
> wrote:
> > […]
>
>
> +1 for the global idea as this would help so much OO programs and framework
> based programs.
>
> But what Sherif said proves as well the limits of the idea. PHP is not
> strongly typed. So each check, should it be type hinting or return type
> hinting, has to be done at runtime , which is bad for performances.
>
> Not talking about the type juggling which could lead the programmer as
> shooting himself.
>
> Julien.Pauli

Hi,

Type juggling is explicitly not allowed in the draft and I would hope
it can remain the same in the final implementation.
That's actually one of the things I want to prevent.
I love PHP because of type juggling which can be very handy at times
but for such feature this would be a total no no.

As for limited applicability, I think that frameworks could benefit
greatly from this as well as systems where you really count on having
the least surprise possible from code. And as more people turn to PHP
to bootstrap their startup, idea or whatnot, having more code quality
features would only help the language to maintain its traction and
improve the life all-around.


Best regards
----
Florin Patan
https://github.com/dlsniper
http://www.linkedin.com/in/florinpatan

---

## #67885 — Ferenc Kovacs — 2013-06-26T15:46:03+00:00

URL: https://externals.io/message/67850#67885 · In reply to: #67877

On Wed, Jun 26, 2013 at 4:48 PM, Johannes Schlüter
<johannes@schlueters.de>wrote:

> 
>
> > […]
>
> So a function author doesn't trust himself and therefore we change the
> language syntax?
>
> johannes
>
>
or not trusting the subsystem that he/she calls, and he/she wants to make a
hard promise about the return value.
I could also mention, that this feature could be used in static analysis
and IDEs(albeit most IDEs out there already supports docblocks).
I'm not saying that this feature is a must, I just wanted to emphasize that
it is a little bit less touchy subject than the (scalar) input typehints.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

---

## #67887 — Stas Malyshev — 2013-06-26T16:02:44+00:00

URL: https://externals.io/message/67850#67887 · In reply to: #67850

Hi!

> Currently PHP doesn't support what could be a good feature for code
> quality, return typing (or if you prefer to call it: return type
> hinting).

What changed since the last time we discussed this?
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

---

## #67894 — Florin Patan — 2013-06-26T16:25:03+00:00

URL: https://externals.io/message/67850#67894 · In reply to: #67887

> Hi!
>
> > […]
>
> What changed since the last time we discussed this?
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227

Hi,


Well I don't want to sound disrespectful, but to be honest, nothing
really. Just the year and the fact that I don't want to allow for
double return types, like object or null or false, like in the other
proposal, if you would read the gist. While I would like to have full
type hinting available, including scalars as well, I think we could
greatly benefit from it even without them.

Like I've said, it's about code quality, something that PHP
programmers lack today badly because PHP is so flexible (don't even
try to argue with that).

As for the argument of don't design features that are optional, like
you've said in the past discussion, here's a optional feature that
everyone uses it today: argument type hinting. Is it optional, yes?
Could we live without it? Yes. Would everyone be sane without it? Not
sure.

PHP is too flexible for its own good. The fact that we have good use
cases for such a feature, just look at the thread so far, makes is
useful to consider. And I don't understand why having return typing
would be such a bad thing when we already have argument typing, which
is a half baked feature (even worst, no?) as it doesn't allow for
scalar hinting. And just having this half baked feature in the
language makes is very unattractive for some people and reduces the
code quality, but for others it's extremely useful, do you want to
argue that we don't need this because .... ?


Best regards
----
Florin Patan
https://github.com/dlsniper
http://www.linkedin.com/in/florinpatan

---

## #67900 — Patrick ALLAERT — 2013-06-26T16:33:38+00:00

URL: https://externals.io/message/67850#67900 · In reply to: #67877

Johannes,

2013/6/26 Johannes Schlüter <johannes@schlueters.de>:
> So a function author doesn't trust himself and therefore we change the
> language syntax?

In the following example:

class Foo {
    public function bar($input) {
        $return = Baz::foo($input);
        if (!$return instanceof ReturnType)
            trigger_error("Cannot divide by zero", E_USER_ERROR); //
or throwing some RuntimeException

        return $return;
    }
}

Baz class can be from a 3rd party software and I may want to enforce
the fact that my Foo::bar() method returns an instance of ReturnType
or throw an exception or trigger an error.
This is moez easily written with this proposition:

class Foo {
    public function <ReturnType> bar($input) {
        return Baz::foo($input);
    }
}

With the same reasoning you had, you would avoid using parameter type
hinting and interfaces for your own project if there's no other people
using it.

---

## #67941 — Richard Quadling — 2013-06-27T12:36:49+00:00

URL: https://externals.io/message/67850#67941 · In reply to: #67900

Hi.

At the moment we can type hint array, classes, interfaces, callable, etc.
As PHP is loosely typed and has type juggling thinking of (or at least
trying to get PHP to enforce) a particular type (string, int, float,
boolean) would be the wrong way to go - too many different behaviours
(block if not a suitable type, block if not a suitable castable value,
nonblocking with auto juggling, etc.). But if we consider that type
juggling is the domain of the type 'scalar', then this would/could act as a
suitable hinter.

If a method has been designed to accept a scalar, there is nothing to stop
the passing in of a resource, callable, closure or object, etc.

But with the type hint, in my head, it is now no different to any other
type hint.

scalar, callable, interface, class, array (and others I'm sure).

This isn't about trying to cast the value to a type - PHP is intrinsically
loosely typed and that is core to everything. But as the core can easily
tell an array from a callable, then a scalar would seem to fit right in.

And if we can have scalar type hinting, scalar return type hinting
would/should also be possible.


Is this a feasible option?





-- 
Richard Quadling
Twitter : @RQuadling
EE : http://e-e.com/M_248814.html
Zend : http://bit.ly/9O8vFY

---

## #68083 — Sara Golemon — 2013-07-09T23:42:34+00:00

URL: https://externals.io/message/67850#68083 · In reply to: #67879

I know this conversation kinda stopped a couple weeks ago, but I want to
throw into the ring that HHVM already has a syntax for return type hinting
and it'd be awesome if we (with my PHP hat on) brought the two
implementations together rather than take them further apart.

In HHVM's case a function might look something like:

function foo(SomeClass $bar, int $baz) : bool {

}

---

## #68084 — Levi Morrison — 2013-07-10T01:07:58+00:00

URL: https://externals.io/message/67850#68084 · In reply to: #68083

> function foo(SomeClass $bar, int $baz) : bool {
>
> }
>

This does have the advantage that function declarations are still grepable.
In my experience this is one of the loudest complaints about previous ideas.

---

## #68086 — Florin Patan — 2013-07-10T08:07:28+00:00

URL: https://externals.io/message/67850#68086 · In reply to: #68083

> I know this conversation kinda stopped a couple weeks ago, but I want to
> throw into the ring that HHVM already has a syntax for return type hinting
> and it'd be awesome if we (with my PHP hat on) brought the two
> implementations together rather than take them further apart.
>
> In HHVM's case a function might look something like:
>
> function foo(SomeClass $bar, int $baz) : bool {
>
> }
>

Hi Sara,


Thanks for the input.
While playing with GO I did found that this type of syntax is a bit better.
Since you brought up the discussion, would you think it would make
more sense to actually start and integrate HHVM into PHP rather that
patching it up?
Or better yet, rewrite it with a HH VM in mind?
I know and fully understand it's a gigantic task but at some point in
a software lifecycle there's only so much patching up you can do
before you can't patch it anymore.
Thanks.


Best regards,
Florin
----
Florin Patan
https://github.com/dlsniper
http://www.linkedin.com/in/florinpatan

---

## #68089 — Maxime Veber — 2013-07-10T09:36:06+00:00

URL: https://externals.io/message/67850#68089 · In reply to: #68086

Hello,

I'm new with php internal. Here is my first answer but i use php everyday.

I think that the return type is needed in php. When you make an interface,
why are you not sure of the return of the function made by the user ?
Of course you can specified it as comment but if you want to be sure of the
return you have to test it and when the class is implementing your
interface...

That's definitively weird, isn't it?

I use PHPStorm (and I'm probably not the only one here, haha) and love so
much the warning when I'm wrong with return type.
Why is it a feature of phpstorm and not of the language ? Weird. Again.

I hope i help !
Bye.
Le 10 juil. 2013 10:08, "Florin Patan" <florinpatan@gmail.com> a écrit :

> 
> > […]
> hinting
> > […]
>
> Hi Sara,
>
>
> Thanks for the input.
> While playing with GO I did found that this type of syntax is a bit better.
> Since you brought up the discussion, would you think it would make
> more sense to actually start and integrate HHVM into PHP rather that
> patching it up?
> Or better yet, rewrite it with a HH VM in mind?
> I know and fully understand it's a gigantic task but at some point in
> a software lifecycle there's only so much patching up you can do
> before you can't patch it anymore.
> Thanks.
>
>
> Best regards,
> Florin
> ----
> Florin Patan
> https://github.com/dlsniper
> http://www.linkedin.com/in/florinpatan

---

## #68092 — Sara Golemon — 2013-07-10T16:49:41+00:00

URL: https://externals.io/message/67850#68092 · In reply to: #68086

> While playing with GO I did found that this type of syntax is a bit better.
>
Yeah, we played with a few formats (including the one originally proposed
and found some issues (like specifying closures as return types:  function
function($foo, $bar) ($foo) { return makeCallback($foo); }   Even if you
add <> around the return type, that's still a bit.. weird.


> Since you brought up the discussion, would you think it would make
> more sense to actually start and integrate HHVM into PHP rather that
> patching it up?
>
HHVM isn't built on PHP (apart from a few very small pieces) so
"integrating" it would mean, well... replacing it.  It's like suggesting to
integrate linux into windows. :p


> Or better yet, rewrite it with a HH VM in mind?
>
I do think we (again, wearing my PHP hat) should look at plugging in LLVM
or something similar.  In my perfect world PHP and HHVM both have enough to
offer that users get to use the tool most appropriate for their needs.  For
HHVM that means working on the build system and the runtime.  For PHP that
means speeding up and extending the language.  We'll never match because
the two projects don't agree on every piece of philosophy, but we can try
to keep close enough to avoid major issues for end users.

-Sara

---

## #68093 — Sara Golemon — 2013-07-10T18:30:59+00:00

URL: https://externals.io/message/67850#68093

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

---

## #68094 — Florin Patan — 2013-07-11T19:30:50+00:00

URL: https://externals.io/message/67850#68094 · In reply to: #68093

> > […]
>
> 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).
>
>
>
> > […]
> 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
> > […]
> mentioned above).  I agree with you that "scalar" would be a nice meta-type.
>
>
>
> > […]
> 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

---

## #68096 — Stas Malyshev — 2013-07-11T19:51:57+00:00

URL: https://externals.io/message/67850#68096 · In reply to: #68094

Hi!

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

We already have a bunch of RFCs about strict typing in PHP:
https://wiki.php.net/rfc/typechecking

So I personally am not sure we need yet another RFC on the topic - given
that we discussed previous ones multiple times.

While HHVM is a very interesting project, their use case is pretty
specific and narrow, and, as I understand, connected to a single
application (albeit running huge traffic numbers). So I'm not sure
copying whatever they do is necessarily good for PHP as a whole. HHVM
case is basically static compilation of monolithic application, as far
as I remember, which is not how PHP is usually run. It is true that such
mode negates many arguments against static typing, but it negates them
only for specific narrow case of HHVM, not for PHP as a whole.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

---

Next page: https://externals.io/message/67850.md?page=2