Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Derick Rethans]

On Thu, 15 Oct 2015, Rowan Collins wrote:

> Korvin Szanto wrote on 14/10/2015 23:55:
> > If I capture the result of a "void" method and check if my result variable
> > with isset(), I'll get false. This sounds like it's void of value to me.
> 
> But why "invent" (as far as PHP is concerned) this new keyword of "void" to
> mean exactly the same thing "null" already means - absence of a definite
> value?

It's already "invented" for PHP anyway: 
http://docs.hhvm.com/manual/en/hack.annotations.examples.php - example 
2.

cheers,
Derick

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Bob Weinand]

> Am 19.10.2015 um 11:46 schrieb Derick Rethans :
> 
> On Thu, 15 Oct 2015, Rowan Collins wrote:
> 
>> Korvin Szanto wrote on 14/10/2015 23:55:
>>> If I capture the result of a "void" method and check if my result variable
>>> with isset(), I'll get false. This sounds like it's void of value to me.
>> 
>> But why "invent" (as far as PHP is concerned) this new keyword of "void" to
>> mean exactly the same thing "null" already means - absence of a definite
>> value?
> 
> It's already "invented" for PHP anyway: 
> http://docs.hhvm.com/manual/en/hack.annotations.examples.php - example 
> 2.
> 
> cheers,
> Derick

When something is "invented" in Hack, … How is that related to PHP?
Hack is a language where a major equal subset is same as in PHP, yes. But 
that's still not a reason to say it were "invented" for PHP.

Please do not use Hack as ultima ratio here, it just is one language like C, 
Java etc. which happens to have more in common with PHP than most. But it still 
is just one other language. It's not PHP.

Bob
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Lester Caine]

On 16/10/15 01:45, Andrea Faulds wrote:
> But why should we change the documentation anyway? We've used void for a
> very long time, at least 17 years[0]. We don't just use it in the PHP
> manual, it's also used in docblocks and the PHP source code's function
> prototypes. It's the commonly-accepted, widely-used term. Until now this
> was uncontroversial.

This are in my book is just the same as 'NULL'. Different styles of
working have different views on how things are interpreted. The function
sets for arrays as originally designed simply modified the target object
without returning any error code or similar value. The 'more modern' way
of doing this may be perhaps to 'return' the array? Or perhaps a count
of the number of elements moved - 0 indicates that nothing has changed.
I can see the reason you want the run time engine to flag an error if I
do $res = sort(xxx); but like many of the 'checks' that seem to be
bloating the run time code, I still see that as a function for a good
IDE rather than a run time error. void is just a documentational flag
that CURRENTLY there is nothing to return, but does not prevent a
modified version that may return a value at some point in the future.

What is 'controversial' is a change from the freedom of the user to
create code the way they want to work, which may wrap a void function in
a return check simply because at some point in the future they plan to
upgrade the simple off the shelf function call with something which
generates the return. I find enforced typing in the same bucket since
while some returns may clearly be 'integer' in other cases a later
development might use the fractional part for some other purpose. Others
seem to think that is bad practice? Having now two different styles of
working is something we simply now have to put up with, but loading the
bias even more in the direction of 'I think that you are wrong' needs to
have a very good case?

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Rowan Collins]

Andrea Faulds wrote on 14/10/2015 22:52:

Good evening,

I'm reviving my Void Return Type RFC, this time for PHP 7.1:

https://wiki.php.net/rfc/void_return_type

Please read it and tell me your thoughts!


My feeling is that it is odd to have both of these be true at once:

- void functions can appear in expressions, where the return value is 
interpreted as null

- "return;" and "return null;" are no longer treated as equivalent

If the intent is to say "you can use this in an expression, but its 
value will always be null so there's no point", then "return null;" 
seems just as valid as "return;", and a typehint of "null" seems to make 
more sense.


I take the point about making intent clear, but can't think of any other 
interpretation of "this function always returns null" than "this 
function has no meaningful result".  In other words, I can't imagine 
ever wanting to use "null" to mean something different from "void" in 
this context.



I can see the point in denying the right to say "return 
some_function_expected_to_return_null();" But in a sense this is no 
different from declaring that a function returns int, and then writing 
"return some_function_expected_to_return_int();"


If a void function can be used in an expression, it can be used in a 
return expression, and if so, it feels natural for the type hint to 
propagate:


function foo(): void { do_something(); }
function wrapped_foo(): void { do_something_else(); return foo(); }
// ERROR: can't specify return value in a void function

"return foo()" is not illegal because foo is declared void, but because 
wrapped_foo is - even though the result is exactly as expected.


Regards,
--
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Chris Riley]

On 14 October 2015 at 22:52, Andrea Faulds  wrote:

> Good evening,
>
> I'm reviving my Void Return Type RFC, this time for PHP 7.1:
>
> https://wiki.php.net/rfc/void_return_type
>
> Please read it and tell me your thoughts!
>
> Thanks.
>
> P.S. As it so (fatefully?) happens, I originally introduced this on 14th
> February, and it's now 14th October, so it's been exactly 8 months!
>
> --
> Andrea Faulds
> http://ajf.me/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Hi,

Semantically, I don't believe that there is sufficient difference between
"returns no value" and "returns a value which has been defined as having no
value" for us to care about it. The main difference you get between return
type of null and a return type of void seems to be some extra fatal errors,
for a developer there seems little value.

>From a user confusion point of view; PHP currently considers return; and
return null; to be equivalent (in fact some code style checkers will
replace one with the other) If (and only if) a function has a return type
of void these two statements are no longer equivalent - one is a fatal
error one is not. For any other return type specification, return null; and
return; would behave the same. This in itself would be enough for me to be
against adding a return type of void.

(also could someone enable my wiki acc: carnage; sent an email ~a week ago
and haven't heard back yet :()

~C

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Björn Larsson]

Den 2015-10-14 kl. 23:52, skrev Andrea Faulds:

Good evening,

I'm reviving my Void Return Type RFC, this time for PHP 7.1:

https://wiki.php.net/rfc/void_return_type

Please read it and tell me your thoughts!

Thanks.

P.S. As it so (fatefully?) happens, I originally introduced this on 
14th February, and it's now 14th October, so it's been exactly 8 months!



Thanks! I have been waiting for this RFC to reopen. Actually
wondered why void wasn't among the reserved words in the
https://wiki.php.net/rfc/reserve_even_more_types_in_php_7.

Regards //Björn


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Rowan Collins]

Korvin Szanto wrote on 14/10/2015 23:55:

If I capture the result of a "void" method and check if my result variable
with isset(), I'll get false. This sounds like it's void of value to me.


But why "invent" (as far as PHP is concerned) this new keyword of "void" 
to mean exactly the same thing "null" already means - absence of a 
definite value?


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Rowan Collins]

Andrea Faulds wrote on 15/10/2015 16:32:
Hmm, this is an interesting case you've pointed out. Being able to do 
`return some_other_void_function();` is something I've desired in 
other languages.


But what if that void function you're calling later adds a return 
value? Now the calling function is returning a value other than null, 
violating its type hint and producing a runtime error.


Well, fundamentally, this is true of anything short of full 
type-checking. The type safety below is self-evident:


function foo(): int { return 42; }
function wrapped_foo(): int { return foo(); }

But foo() could later be changed to this:

function foo(): string { return 'The Answer'; }

The wrapped_foo() typehint is now broken. That's not really any 
different from foo() starting off as void/returns-null and adding a 
return value.


In both cases, a static analyser could detect the discrepancy, but the 
Zend Engine will not, until the function is executed.



It's a shame there's no "tail call this other function and discard its 
result" construct. 


Yeah, I guess what you really want is for a void function to be able to 
"goto foo();"


Regards,
--
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Andrea Faulds]

Hi Rowan,

Rowan Collins wrote:

I can see the point in denying the right to say "return
some_function_expected_to_return_null();" But in a sense this is no
different from declaring that a function returns int, and then writing
"return some_function_expected_to_return_int();"

If a void function can be used in an expression, it can be used in a
return expression, and if so, it feels natural for the type hint to
propagate:

function foo(): void { do_something(); }
function wrapped_foo(): void { do_something_else(); return foo(); }
// ERROR: can't specify return value in a void function

"return foo()" is not illegal because foo is declared void, but because
wrapped_foo is - even though the result is exactly as expected.


Hmm, this is an interesting case you've pointed out. Being able to do 
`return some_other_void_function();` is something I've desired in other 
languages.


But what if that void function you're calling later adds a return value? 
Now the calling function is returning a value other than null, violating 
its type hint and producing a runtime error.


It's a shame there's no "tail call this other function and discard its 
result" construct.


Thanks.


--
Andrea Faulds
http://ajf.me/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Rowan Collins]

Andrea Faulds wrote on 15/10/2015 16:32:

Hi Rowan,

Rowan Collins wrote:

But why "invent" (as far as PHP is concerned) this new keyword of "void"
to mean exactly the same thing "null" already means - absence of a
definite value?


They don't mean exactly the same thing. null is a value to represent a 
lack of a value. But there's also the concept of *no value at all* (a 
missing variable, say). The closest we have to that in PHP already 
would actually be `unset`, but that's a strange choice given it's not 
what we use in documentation (function prototypes, PHP manual, PHPDoc, 
etc. use `void`), and it's tainted by the bizarro `(unset)` cast which 
casts to null. 


Oh, lord, not this discussion again! PHP has no concept of a variable 
being in the "state" of unset; it has programmer hints to warn you if 
you read before writing, and a couple of odd constructs which let you 
access the current symbol table as a dictionary.


The manual has some weird wording in places which implies that a 
variable takes on a type when first used, but in practice the rule is 
much simpler: any variable which hasn't had a value assigned yet is 
considered to have the value NULL, and normal cast rules apply from 
there. The same is true of missing array keys, object properties, 
unset() variables, unspecified return values, etc, etc, etc. They are 
all NULL.


You could add a warning for "function foo() { return; } $a = foo();" to 
match "$x = []; $a = $x['foo'];", but $a would still unambiguously 
contain the value NULL in both cases, and outside of some odd 
applications like templating, it is *values* the program should be 
concerned with, not the *reason* for those values.


Regards,
--
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Andrea Faulds]

Hi Rowan,

Rowan Collins wrote:

But why "invent" (as far as PHP is concerned) this new keyword of "void"
to mean exactly the same thing "null" already means - absence of a
definite value?


They don't mean exactly the same thing. null is a value to represent a 
lack of a value. But there's also the concept of *no value at all* (a 
missing variable, say). The closest we have to that in PHP already would 
actually be `unset`, but that's a strange choice given it's not what we 
use in documentation (function prototypes, PHP manual, PHPDoc, etc. use 
`void`), and it's tainted by the bizarro `(unset)` cast which casts to null.


Thanks.

--
Andrea Faulds
http://ajf.me/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Pedro Cordeiro]

I've been thinking about what PHP should do when accessing the return value
of a `void` function, and so far, I think the consistent thing should be to
get NULL, while throwing an E_NOTICE.

$a = $b; //$b wasn't initiated.

This does the same thing. I tried accessing what was supposed to be
'nothing' ($b), and got NULL with an E_NOTICE being thrown.

function myFunc() : void { ... }
$a = myFunc();

I see no reason why this should silently assign NULL to $a, *specially* with
"return null;" being explicitly forbidden.

My point is: we already use an implicit NULL return on functions with
missing return values (or with "return ;"), but now we're explicitly
prohibiting even a NULL return. The behaviour should be consistent (NULL
should be accessed, as for all undefined things), with an E_NOTICE.

function myFunc() { return ; }
$a = myFunc();

Should assign NULL to $a and *not* throw an E_NOTICE (this is the current
status), because a return type was not forbidden with the keyword 'void'.

2015-10-15 13:00 GMT-03:00 Rowan Collins :

> Andrea Faulds wrote on 15/10/2015 16:32:
>
>> Hmm, this is an interesting case you've pointed out. Being able to do
>> `return some_other_void_function();` is something I've desired in other
>> languages.
>>
>> But what if that void function you're calling later adds a return value?
>> Now the calling function is returning a value other than null, violating
>> its type hint and producing a runtime error.
>>
>
> Well, fundamentally, this is true of anything short of full type-checking.
> The type safety below is self-evident:
>
> function foo(): int { return 42; }
> function wrapped_foo(): int { return foo(); }
>
> But foo() could later be changed to this:
>
> function foo(): string { return 'The Answer'; }
>
> The wrapped_foo() typehint is now broken. That's not really any different
> from foo() starting off as void/returns-null and adding a return value.
>
> In both cases, a static analyser could detect the discrepancy, but the
> Zend Engine will not, until the function is executed.
>
>
> It's a shame there's no "tail call this other function and discard its
>> result" construct.
>>
>
> Yeah, I guess what you really want is for a void function to be able to
> "goto foo();"
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Andrea Faulds]

Hey Chris,

Chris Riley wrote:

Semantically, I don't believe that there is sufficient difference between
"returns no value" and "returns a value which has been defined as having no
value" for us to care about it. The main difference you get between return
type of null and a return type of void seems to be some extra fatal errors,
for a developer there seems little value.

 From a user confusion point of view; PHP currently considers return; and
return null; to be equivalent (in fact some code style checkers will
replace one with the other) If (and only if) a function has a return type
of void these two statements are no longer equivalent - one is a fatal
error one is not. For any other return type specification, return null; and
return; would behave the same. This in itself would be enough for me to be
against adding a return type of void.


This is true, but `void` isn't an ordinary return type. It exists to 
ensure a function doesn't return anything, unlike other return types 
which exist to ensure a function returns a specific thing.


`return null;` is *technically* equivalent to `return;`, but it's not 
quite the same in intent, usually. We could special-case it and allow 
it, but why? The return value isn't supposed to be used, why should we 
allow you to specify it? A void function in PHP does technically produce 
a result of null, but it might as well be false or -1 or whatever for 
all we care. Also, if `return null;` is to work, should `return(null);` 
also work? How about `return \null;`? `return SOME_NULL_CONSTANT;`? It 
seems silly to me since, again, the return value is insigificant.


Thanks.
--
Andrea Faulds
http://ajf.me/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Andrea Faulds]

Hi Larry,

Larry Garfield wrote:

On 10/14/2015 06:30 PM, Andrea Faulds wrote:

This would be strange. The manual doesn't say `null`, and I can't
think of any language which uses `null` as the return type in this
situation, even when they have the same implicit-null-return behaviour
that PHP has (see the email you're replying to).

Also, wouldn't you expect this to behave like existing type hints, and
let you return a null value from any source? But that's not what you
would actually want, right?

Thanks.


Well, that depends on the intent here.  In practice, is the intent to
add a "no return at all" type of function (ie, $a = foo() is a syntax
error now where it was not before), or to make it explicit that the only
legal return is null (even if implicitly that means having a non-early
return statement is pointless)?  Those are the two options.  That may or
may not dictate the keyword that gets used.


It would seem ideal to have "true" void functions which can't be used as 
expressions, i.e. producing an error if you try to use them like in your 
example. But they'd cause a backwards-compatibility headache, and I'm 
not sure they're a good idea anyway. Every function call being an 
expression is pretty handy. You can safely capture the return value of a 
callback and pass it along, for instance.


In a sense, what this RFC offers might be called a compromise. It 
enforces the rules of `void` within the function, but at the end of the 
day the caller still gets a null out of it since that's what PHP's 
always done.



It definitely sounds like you're favoring the second (as that's what the
RFC says).  Which may or make not make "void" an odd keyword to choose
when what's actually happening is NULL getting returned.  Is NULL a
void?  (There's a deep philosophical question...)


It's an interesting question. There's some precedent for using `void` in 
this way even though the functions aren't "truly" void. I mostly like 
`void` because it's the customary keyword to use, though. Everyone knows 
what a 'void function' is.



As I said, I don't have a strong opinion on the subject yet.  I'm just
trying to distil the discussion down to as small a question as possible.
:-)


I appreciate your efforts. I have a tendency to be a bit verbose in my 
writing, so providing clarity is helpful. :)


Thanks.
--
Andrea Faulds
http://ajf.me/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Marc Bennewitz]

On 10/15/2015 01:19 AM, Larry Garfield wrote:
On 10/14/2015 06:00 PM, Andrea Faulds wrote:  >> Both you and Stas have said this, but it's only true if we solely 
>> consider C-like languages. Other languages do different things. In 
>> the PHP manual, Hack, TypeScript, ActionScript, and most likely 
other >> languages (these are just off the top of my head), `void` 
functions >> do still have an implicit result. >> >> All of these 
languages would have had the choice to do what you're >> suggesting and 
use `null`, or its equivalent (`undefined` for >> TypeScript and 
ActionScript). They didn't. Why? If I had to guess, >> there's at least 
three reasons. For one, void is the word languages >> usually use for 
this. For another, `void` and `null` they mean >> different things. 
`void` signifies a function isn't returning >> anything. `null` 
signifies a function that *returns null*, regardless >> of where that 
null came from. `function foo(): null { return >> 
some_probably_null_returning_function(); }` should surely be legal >> 
with a `null` type hint, yet it's nonsensical code. Finally, making a >> 
function truly "return nothing", i.e. disallowing its use as an >> 
expression/rvalue, breaks some use cases, like passing along the >> 
result of a callback. >> >> PHP would neither be the first nor the last 
to be using `void` in >> this way. >> >>> If the union types RFC[2] 
passes it >>> makes sense to allow `Foo | null` which allows something 
of type `Foo` >>> or `null`. To me it makes sense that if you then 
remove `Foo` you are >>> left with `null`, not `void`. My personal 
recommendation because of >>> this would be to use `null` for the return 
type and instead of `void`. >> >> `null` would be a weird type, because 
it doesn't make sense as a >> parameter type, and as a return type, you 
don't really want to >> enforce returning null, you want to enforce not 
returning at all (see >> the example above). It feels like a poor man's 
substitute to me. >> >> Thanks. > > The tricky part here is that saying 
a function does not return is not > something PHP currently does: > > 
https://3v4l.org/HtAuC > > No return implicitly returns NULL, which you 
can assign to a variable > if, for some strange reason, you were so 
inclined. So this would be > more than "just" a syntactic documentation 
feature. > > Which I believe gives the following options: > > 1) Change 
the language behavior such that > > function foo() : void { ...} > $a = 
foo(); > > Is a syntax error (because there really was nothing returned 
to > assign), rather than resulting in $a having a value of NULL. > > 2) 
Use null as a "type" (which I agree feels weird just saying it), > such 
that: > > function foo() : null { ...} > $a = foo(); > > and > > 
function foo() { ...} > $a = foo(); > > are identical. The former would 
impact the contents of the function > (eg, a non-empty return would be a 
parse error), but the external > result is the same ($a == NULL). > > 3) 
Use the "void" keyword, but give it the same effect as option 2. > > The 
RFC currently seems to propose option 3 (based on the "Use of void > 
functions in expressions" section). I don't have a strong feeling at > 
this point about which option I'd prefer. >

Option 4)

// implicit return void
function foo () { return; }

// explicit return void
function foo () : void { return; };

// syntax error if returning something on explicit return void
function foo () : void { return null; };

// syntax error on using return value of explicit return void
function foo () : void { return; };
$bar = foo();

// return NULL on implicit return void (this could also give a 
warning/notice/deprecated error)

function foo () { return; };
$bar = foo(); // NULL

// mixing return void with any other return values could also result in 
a warning/notice/deprecated error

function foo () { if ($bar) return; return $bar; };


--Larry Garfield  >


I really like this as in my opinion if a function doesn't return 
something it should be part of the function signature and it really 
helps to avoid mistakes on writing code.


Marc

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Rowan Collins]

On 15 October 2015 20:33:04 BST, Andrea Faulds  wrote:
>> Obviously, type hints for internal functions are a bit weird anyway,
>but
>> there's no reason to assume that every function documented as void
>would
>> suddenly be annotated in the Engine as such and start returning
>notices.
>
>Why shouldn't it? For the scalar types, internal and userland functions behave 
>almost the same.

Just for the same reason that an existing function that uses bare "return;" 
won't automatically be considered "void" - nobody has  explicitly decided that 
that's the intent.

Sure, internal functions whose value shouldn't be used *could* be marked void, 
and those would start raising Notices if that was part of void's behaviour. But 
there would only be a blizzard of Notices if someone bulk updated every 
function in core which happens to return null, which doesn't seem like an 
automatic part of creating a void return behaviour.  Especially if the whole 
point is that "void" signifies something more than "always returns null".

Since it's been mentioned a couple of times, I'd like to say that although the 
documentation is official, I think it should be considered descriptive not 
prescriptive - if it labels something as void, but the Engine doesn't consider 
it so, the manual would be wrong, not the Engine.

Regards,
-- 
Rowan Collins
[IMSoP]

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Korvin Szanto]

On Thu, Oct 15, 2015 at 4:21 PM Rowan Collins 
wrote:

> On 15 October 2015 20:33:04 BST, Andrea Faulds  wrote:
> >> Obviously, type hints for internal functions are a bit weird anyway,
> >but
> >> there's no reason to assume that every function documented as void
> >would
> >> suddenly be annotated in the Engine as such and start returning
> >notices.
> >
> >Why shouldn't it? For the scalar types, internal and userland functions
> behave almost the same.
>
> Just for the same reason that an existing function that uses bare
> "return;" won't automatically be considered "void" - nobody has  explicitly
> decided that that's the intent.
>
> Sure, internal functions whose value shouldn't be used *could* be marked
> void, and those would start raising Notices if that was part of void's
> behaviour. But there would only be a blizzard of Notices if someone bulk
> updated every function in core which happens to return null, which doesn't
> seem like an automatic part of creating a void return behaviour.
> Especially if the whole point is that "void" signifies something more than
> "always returns null".
>
> Since it's been mentioned a couple of times, I'd like to say that although
> the documentation is official, I think it should be considered descriptive
> not prescriptive - if it labels something as void, but the Engine doesn't
> consider it so, the manual would be wrong, not the Engine.
>

Could we change the documentation for existing functions to return null,
and start using void properly moving forward?

Thanks,
Korvin

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Andrea Faulds]

Hi Korvin,

Korvin Szanto wrote:


Could we change the documentation for existing functions to return null,
and start using void properly moving forward?



As I have stated several times now, we're not "misusing" void. PHP is 
not the only language to use the word in this manner.


But why should we change the documentation anyway? We've used void for a 
very long time, at least 17 years[0]. We don't just use it in the PHP 
manual, it's also used in docblocks and the PHP source code's function 
prototypes. It's the commonly-accepted, widely-used term. Until now this 
was uncontroversial.


Why should we move heaven and earth when there's nothing wrong?

[0] 
https://web.archive.org/web/19991002011107/http://php.net/manual/function.sort.php3



--
Andrea Faulds
http://ajf.me/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Andrea Faulds]

Hey Chris,

Chris Riley wrote:

Semantically, I don't believe that there is sufficient difference between
"returns no value" and "returns a value which has been defined as having no
value" for us to care about it. The main difference you get between return
type of null and a return type of void seems to be some extra fatal errors,
for a developer there seems little value.

 From a user confusion point of view; PHP currently considers return; and
return null; to be equivalent (in fact some code style checkers will
replace one with the other) If (and only if) a function has a return type
of void these two statements are no longer equivalent - one is a fatal
error one is not. For any other return type specification, return null; and
return; would behave the same. This in itself would be enough for me to be
against adding a return type of void.


This is true, but `void` isn't an ordinary return type. It exists to 
ensure a function doesn't return anything, unlike other return types 
which exist to ensure a function returns a specific thing.


`return null;` is *technically* equivalent to `return;`, but it's not 
quite the same in intent, usually. We could special-case it and allow 
it, but why? The return value isn't supposed to be used, why should we 
allow you to specify it? A void function in PHP does technically produce 
a result of null, but it might as well be false or -1 or whatever for 
all we care. Also, if `return null;` is to work, should `return(null);` 
also work? How about `return \null;`? `return SOME_NULL_CONSTANT;`? It 
seems silly to me since, again, the return value is insigificant.


Thanks.
--
Andrea Faulds
http://ajf.me/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Andrea Faulds]

Hi Pedro,

Pedro Cordeiro wrote:

I've been thinking about what PHP should do when accessing the return value
of a `void` function, and so far, I think the consistent thing should be to
get NULL, while throwing an E_NOTICE.


We could do this, but I do wonder if it might cause a lot of E_NOTICEs 
to pop up for existing code, assuming we applied this to built-in PHP 
functions.


I'm not sure.

Thanks.
--
Andrea Faulds
http://ajf.me/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Chris Riley]

On 15 October 2015 at 16:32, Andrea Faulds  wrote:


> In a sense, what this RFC offers might be called a compromise. It enforces
> the rules of `void` within the function, but at the end of the day the
> caller still gets a null out of it since that's what PHP's always done.
>
>
>
If this truly is the case, then all you get over hinting void as the return
type instead of null is a fatal error for return null; Sure you can argue
for capturing intent but realistically the difference in intent between
'returns no value' and 'does not return a value' is something for
philosophers to argue over not programmers. ;)

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Pedro Cordeiro]

>
> this would make the "void" keyword feel more meaningful.


I, too, had issues trying to understand what "void" was bringing to the
table. IMHO, it should warn people thinking some specific function/method
returns a value when it doesn't, not protect against some dev forgetting
the function he's writing should not return something.

IMHO, it's far more important to warn "Hey, this function returns NOTHING,
don't try to use its value because it doesn't exist!" then it is to warn
"Hey, this function can't return anything, stop trying to return things!".

Throwing an E_NOTICE when accessing a void return value would make perfect
sense, as the compiler would strict check that the function author defined
a no-return and indeed returned nothing and would also warn whoever was
calling the function that it doesn't return anything.

> We could do this, but I do wonder if it might cause a lot of E_NOTICEs to
pop up for existing code, assuming we applied this to built-in PHP
functions.

My proposal is to only throw an E_NOTICE when accessing a return value from
a function that is explicitly marked with "void". A function with no return
("return ;") but with no ": void" on the signature would not necessarily
throw an E_NOTICE.

function myFunc() { return ; }
$a = myFunc(); //NULL should be assigned to $a silently, like it is today.
function myOtherFunc() : void { return ; }
$b = myOtherFunc(); //NULL should be assigned to $b, but an E_NOTICE is
thrown.

2015-10-15 13:34 GMT-03:00 Andrea Faulds :

> Hi Pedro,
>
> Pedro Cordeiro wrote:
>
>> I've been thinking about what PHP should do when accessing the return
>> value
>> of a `void` function, and so far, I think the consistent thing should be
>> to
>> get NULL, while throwing an E_NOTICE.
>>
>
> We could do this, but I do wonder if it might cause a lot of E_NOTICEs to
> pop up for existing code, assuming we applied this to built-in PHP
> functions.
>
> I'm not sure.
>
> Thanks.
> --
> Andrea Faulds
> http://ajf.me/
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Rowan Collins]

Pedro Cordeiro wrote on 15/10/2015 17:14:
I've been thinking about what PHP should do when accessing the return 
value of a `void` function, and so far, I think the consistent thing 
should be to get NULL, while throwing an E_NOTICE.


$a = $b; //$b wasn't initiated.

This does the same thing. I tried accessing what was supposed to be 
'nothing' ($b), and got NULL with an E_NOTICE being thrown.


function myFunc() : void { ... }
$a = myFunc();

I see no reason why this should silently assign NULL to $a, 
*specially* with "return null;" being explicitly forbidden. ... The 
behaviour should be consistent (NULL should be accessed, as for all 
undefined things), with an E_NOTICE.


I don't know how easy this would be to implement, but I agree that this 
would make the "void" keyword feel more meaningful.


Does the Engine have a way to know whether a return value is being used 
or discarded for optimisation purposes? If so, could that logic be 
hooked to provide the Notice?


Regards,
--
Rowan Collins
[IMSoP]

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Rowan Collins]

Andrea Faulds wrote on 15/10/2015 17:34:

Hi Pedro,

Pedro Cordeiro wrote:
I've been thinking about what PHP should do when accessing the return 
value
of a `void` function, and so far, I think the consistent thing should 
be to

get NULL, while throwing an E_NOTICE.


We could do this, but I do wonder if it might cause a lot of E_NOTICEs 
to pop up for existing code, assuming we applied this to built-in PHP 
functions.


I'm not sure. 



The way Pedro described it, it wouldn't apply to any existing functions 
because they wouldn't be declared void.


Obviously, type hints for internal functions are a bit weird anyway, but 
there's no reason to assume that every function documented as void would 
suddenly be annotated in the Engine as such and start returning notices.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Björn Larsson]

Den 2015-10-15 kl. 09:04, skrev Björn Larsson:

Den 2015-10-14 kl. 23:52, skrev Andrea Faulds:

Good evening,

I'm reviving my Void Return Type RFC, this time for PHP 7.1:

https://wiki.php.net/rfc/void_return_type

Please read it and tell me your thoughts!

Thanks.

P.S. As it so (fatefully?) happens, I originally introduced this on 
14th February, and it's now 14th October, so it's been exactly 8 months!



Thanks! I have been waiting for this RFC to reopen. Actually
wondered why void wasn't among the reserved words in the
https://wiki.php.net/rfc/reserve_even_more_types_in_php_7.

Regards //Björn


Hm... Just noticed that HACK allows void as return type. Wonder
how it works and motivation for having it? Mention in RFC?

//Björn


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Andrea Faulds]

Hi Rowan,

Rowan Collins wrote:

Andrea Faulds wrote on 15/10/2015 17:34:

Hi Pedro,

Pedro Cordeiro wrote:

I've been thinking about what PHP should do when accessing the return
value
of a `void` function, and so far, I think the consistent thing should
be to
get NULL, while throwing an E_NOTICE.


We could do this, but I do wonder if it might cause a lot of E_NOTICEs
to pop up for existing code, assuming we applied this to built-in PHP
functions.

I'm not sure.



The way Pedro described it, it wouldn't apply to any existing functions
because they wouldn't be declared void.

Obviously, type hints for internal functions are a bit weird anyway, but
there's no reason to assume that every function documented as void would
suddenly be annotated in the Engine as such and start returning notices.


Why shouldn't it? For the scalar types, internal and userland functions 
behave almost the same.


I'd like there the two to converge, not diverge.

--
Andrea Faulds
http://ajf.me/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Ryan Pallas]

On Wed, Oct 14, 2015 at 4:46 PM, Levi Morrison  wrote:
>
>
> I agree that `void` doesn't make sense given that we document that
> `return;` will return null[1].  If the union types RFC[2] passes it
> makes sense to allow `Foo | null` which allows something of type `Foo`
> or `null`. To me it makes sense that if you then remove `Foo` you are
> left with `null`, not `void`. My personal recommendation because of
> this would be to use `null` for the return type and instead of `void`.
>
> Also, I do not think this feature is pointless. For instance, it has
> value in interfaces. Declaring that a method does not return a value
> means implementors cannot accidentally return something. This is
> better than just documenting that it should not be done.


+1 these are my thoughts exactly. I would be for it if it was null, and
interfaces is exactly why I would be for it.

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Stanislav Malyshev]

Hi!

> I'm reviving my Void Return Type RFC, this time for PHP 7.1:
> 
> https://wiki.php.net/rfc/void_return_type
> 
> Please read it and tell me your thoughts!

I still see no point in this, as every PHP function actually returns
something (at least null). So this type would not actually be right and
would not reflect what actually is happening.

Moreover, I don't see any scenario where some code depends on a function
not returning something explicitly (i.e. does not use return value) but
function actually returns something explicitly and the calling code
breaks. This appears to be impossible, and thus there's no reason to
declare a function "void" except purely for documentation purposes.
Adding keywords to the language just to document this does not look to
me like a good idea.

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Andrea Faulds]

Hi Levi,

Levi Morrison wrote:

On Wed, Oct 14, 2015 at 4:00 PM, Stanislav Malyshev  wrote:

Hi!


I'm reviving my Void Return Type RFC, this time for PHP 7.1:

https://wiki.php.net/rfc/void_return_type

Please read it and tell me your thoughts!


I still see no point in this, as every PHP function actually returns
something (at least null). So this type would not actually be right and
would not reflect what actually is happening.


I agree that `void` doesn't make sense given that we document that
`return;` will return null[1].


Both you and Stas have said this, but it's only true if we solely 
consider C-like languages. Other languages do different things. In the 
PHP manual, Hack, TypeScript, ActionScript, and most likely other 
languages (these are just off the top of my head), `void` functions do 
still have an implicit result.


All of these languages would have had the choice to do what you're 
suggesting and use `null`, or its equivalent (`undefined` for TypeScript 
and ActionScript). They didn't. Why? If I had to guess, there's at least 
three reasons. For one, void is the word languages usually use for this. 
For another, `void` and `null` they mean different things. `void` 
signifies a function isn't returning anything. `null` signifies a 
function that *returns null*, regardless of where that null came from. 
`function foo(): null { return some_probably_null_returning_function(); 
}` should surely be legal with a `null` type hint, yet it's nonsensical 
code. Finally, making a function truly "return nothing", i.e. 
disallowing its use as an expression/rvalue, breaks some use cases, like 
passing along the result of a callback.


PHP would neither be the first nor the last to be using `void` in this way.


If the union types RFC[2] passes it
makes sense to allow `Foo | null` which allows something of type `Foo`
or `null`. To me it makes sense that if you then remove `Foo` you are
left with `null`, not `void`. My personal recommendation because of
this would be to use `null` for the return type and instead of `void`.


`null` would be a weird type, because it doesn't make sense as a 
parameter type, and as a return type, you don't really want to enforce 
returning null, you want to enforce not returning at all (see the 
example above). It feels like a poor man's substitute to me.


Thanks.

--
Andrea Faulds
http://ajf.me/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Andrea Faulds]

Good evening,

I'm reviving my Void Return Type RFC, this time for PHP 7.1:

https://wiki.php.net/rfc/void_return_type

Please read it and tell me your thoughts!

Thanks.

P.S. As it so (fatefully?) happens, I originally introduced this on 14th 
February, and it's now 14th October, so it's been exactly 8 months!


--
Andrea Faulds
http://ajf.me/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Andrea Faulds]

Hi Stas,

Stanislav Malyshev wrote:


I still see no point in this, as every PHP function actually returns
something (at least null). So this type would not actually be right and
would not reflect what actually is happening.


It wouldn't be incorrect. Not all languages with `void` prevent a 
function's use as an expression (or 'rvalue' in C parlance). In some, it 
merely requires the function not to explicitly return a value.


And, heck, we use void in the PHP manual all the time.


Moreover, I don't see any scenario where some code depends on a function
not returning something explicitly (i.e. does not use return value) but
function actually returns something explicitly and the calling code
breaks. This appears to be impossible,


It most likely is, but it's not the only case that matters. What if you 
mistakenly return a value in a function that's not supposed to? This 
would catch you out.



and thus there's no reason to
declare a function "void" except purely for documentation purposes.
Adding keywords to the language just to document this does not look to
me like a good idea.


I feel that the basic facts about a function should be in the signature, 
and shouldn't have to be hidden in a comment, if only because it's more 
concicse and keeps information about parameters on the same line as the 
parameters themselves. Unlike comments, type hints can't lie, because 
they're actually enforced.


But, yes, it is mostly just useful for documentation. I can understand 
your objection there.


Thanks.
--
Andrea Faulds
http://ajf.me/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Stanislav Malyshev]

Hi!

> And, heck, we use void in the PHP manual all the time.

Yes, because PHP manual *is* the documentation :) Note that function
descriptions in the manual, while they are similar to PHP syntax, aren't
actually valid PHP, even after scalar typing introduction. Bizarrely
enough, they don't even match the return type syntax.

> It most likely is, but it's not the only case that matters. What if you
> mistakenly return a value in a function that's not supposed to? This
> would catch you out.

Why would I care about such a mistake? Why would I care so much that I
would need a special language-level construct to catch it? How many such
mistakes happen and are they critical enough to have the engine
bothering with going after them? I think such mistakes are extremely
rare and insignificant.

> I feel that the basic facts about a function should be in the signature,
> and shouldn't have to be hidden in a comment, if only because it's more

I guess we disagree here, because I do not think comments are "hidden",
and I do not think signature of the function should be the comment. In
fact, in Java for example (which seems to be the model language for the
strict typing aficionados) it is long standing best practice to actually
verify the javadoc comments as part of the build and fail the build if
they are missing or wrong. I am not advocating for doing (or not doing
:) this in PHP, but I do say documentation is not "hidden" and strict
typing is not the same as documentation. Moreover, in this case strict
typing implies something that is outright false - the function that is
declared void does return a value, namely null. Even worse, if you do
try to return exactly the same value, the RFC requires failure in this
case, which makes zero sense as precisely the same thing happens in both
cases.

> concicse and keeps information about parameters on the same line as the
> parameters themselves. Unlike comments, type hints can't lie, because
> they're actually enforced.

In fact, it is the opposite - as I said above, that particular type does
lie, and it has to, because what it tries to express actually does not
exist in PHP.
I might be reluctantly ok with tolerating purely documentation type, but
tolerating purely documentation type that is in fact untrue does not
look good to me.
-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Korvin Szanto]

On Wed, Oct 14, 2015 at 3:47 PM Levi Morrison  wrote:

> On Wed, Oct 14, 2015 at 4:00 PM, Stanislav Malyshev 
> wrote:
> > Hi!
> >
> >> I'm reviving my Void Return Type RFC, this time for PHP 7.1:
> >>
> >> https://wiki.php.net/rfc/void_return_type
> >>
> >> Please read it and tell me your thoughts!
> >
> > I still see no point in this, as every PHP function actually returns
> > something (at least null). So this type would not actually be right and
> > would not reflect what actually is happening.
>
> I agree that `void` doesn't make sense given that we document that
> `return;` will return null[1].  If the union types RFC[2] passes it
> makes sense to allow `Foo | null` which allows something of type `Foo`
> or `null`. To me it makes sense that if you then remove `Foo` you are
> left with `null`, not `void`. My personal recommendation because of
> this would be to use `null` for the return type and instead of `void`.
>

Isn't null supposed to mean the absense of a value and not take the place
of a value in PHP though? Didn't we just have a long conversation about
this in a thread about PHPSadness?

If I capture the result of a "void" method and check if my result variable
with isset(), I'll get false. This sounds like it's void of value to me.


> Also, I do not think this feature is pointless. For instance, it has
> value in interfaces. Declaring that a method does not return a value
> means implementors cannot accidentally return something. This is
> better than just documenting that it should not be done.
>

This is what I was thinking too, I'm not sure that there's much value
beyond that


>   [1]: http://php.net/manual/en/function.return.php
>   [2]: https://wiki.php.net/rfc/union_types
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Levi Morrison]

On Wed, Oct 14, 2015 at 4:00 PM, Stanislav Malyshev  wrote:
> Hi!
>
>> I'm reviving my Void Return Type RFC, this time for PHP 7.1:
>>
>> https://wiki.php.net/rfc/void_return_type
>>
>> Please read it and tell me your thoughts!
>
> I still see no point in this, as every PHP function actually returns
> something (at least null). So this type would not actually be right and
> would not reflect what actually is happening.

I agree that `void` doesn't make sense given that we document that
`return;` will return null[1].  If the union types RFC[2] passes it
makes sense to allow `Foo | null` which allows something of type `Foo`
or `null`. To me it makes sense that if you then remove `Foo` you are
left with `null`, not `void`. My personal recommendation because of
this would be to use `null` for the return type and instead of `void`.

Also, I do not think this feature is pointless. For instance, it has
value in interfaces. Declaring that a method does not return a value
means implementors cannot accidentally return something. This is
better than just documenting that it should not be done.

  [1]: http://php.net/manual/en/function.return.php
  [2]: https://wiki.php.net/rfc/union_types

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Larry Garfield]

On 10/14/2015 06:00 PM, Andrea Faulds wrote:
Both you and Stas have said this, but it's only true if we solely 
consider C-like languages. Other languages do different things. In the 
PHP manual, Hack, TypeScript, ActionScript, and most likely other 
languages (these are just off the top of my head), `void` functions do 
still have an implicit result.


All of these languages would have had the choice to do what you're 
suggesting and use `null`, or its equivalent (`undefined` for 
TypeScript and ActionScript). They didn't. Why? If I had to guess, 
there's at least three reasons. For one, void is the word languages 
usually use for this. For another, `void` and `null` they mean 
different things. `void` signifies a function isn't returning 
anything. `null` signifies a function that *returns null*, regardless 
of where that null came from. `function foo(): null { return 
some_probably_null_returning_function(); }` should surely be legal 
with a `null` type hint, yet it's nonsensical code. Finally, making a 
function truly "return nothing", i.e. disallowing its use as an 
expression/rvalue, breaks some use cases, like passing along the 
result of a callback.


PHP would neither be the first nor the last to be using `void` in this 
way.



If the union types RFC[2] passes it
makes sense to allow `Foo | null` which allows something of type `Foo`
or `null`. To me it makes sense that if you then remove `Foo` you are
left with `null`, not `void`. My personal recommendation because of
this would be to use `null` for the return type and instead of `void`.


`null` would be a weird type, because it doesn't make sense as a 
parameter type, and as a return type, you don't really want to enforce 
returning null, you want to enforce not returning at all (see the 
example above). It feels like a poor man's substitute to me.


Thanks.


The tricky part here is that saying a function does not return is not 
something PHP currently does:


https://3v4l.org/HtAuC

No return implicitly returns NULL, which you can assign to a variable 
if, for some strange reason, you were so inclined.  So this would be 
more than "just" a syntactic documentation feature.


Which I believe gives the following options:

1) Change the language behavior such that

function foo() : void { ...}
$a = foo();

Is a syntax error (because there really was nothing returned to assign), 
rather than resulting in $a having a value of NULL.


2) Use null as a "type" (which I agree feels weird just saying it), such 
that:


function foo() : null { ...}
$a = foo();

and

function foo() { ...}
$a = foo();

are identical.  The former would impact the contents of the function 
(eg, a non-empty return would be a parse error), but the external result 
is the same ($a == NULL).


3) Use the "void" keyword, but give it the same effect as option 2.

The RFC currently seems to propose option 3 (based on the "Use of void 
functions in expressions" section).  I don't have a strong feeling at 
this point about which option I'd prefer.


--Larry Garfield

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Larry Garfield]

On 10/14/2015 06:30 PM, Andrea Faulds wrote:

Which I believe gives the following options:


1) Change the language behavior such that

function foo() : void { ...}
$a = foo();

Is a syntax error (because there really was nothing returned to assign),
rather than resulting in $a having a value of NULL.


As the RFC notes, this breaks things, and is inconsistent with how PHP 
already does things.



2) Use null as a "type" (which I agree feels weird just saying it), such
that:

function foo() : null { ...}
$a = foo();

and

function foo() { ...}
$a = foo();

are identical.  The former would impact the contents of the function
(eg, a non-empty return would be a parse error), but the external result
is the same ($a == NULL).


This would be strange. The manual doesn't say `null`, and I can't 
think of any language which uses `null` as the return type in this 
situation, even when they have the same implicit-null-return behaviour 
that PHP has (see the email you're replying to).


Also, wouldn't you expect this to behave like existing type hints, and 
let you return a null value from any source? But that's not what you 
would actually want, right?


Thanks.


Well, that depends on the intent here.  In practice, is the intent to 
add a "no return at all" type of function (ie, $a = foo() is a syntax 
error now where it was not before), or to make it explicit that the only 
legal return is null (even if implicitly that means having a non-early 
return statement is pointless)?  Those are the two options.  That may or 
may not dictate the keyword that gets used.


It definitely sounds like you're favoring the second (as that's what the 
RFC says).  Which may or make not make "void" an odd keyword to choose 
when what's actually happening is NULL getting returned.  Is NULL a 
void?  (There's a deep philosophical question...)


As I said, I don't have a strong opinion on the subject yet.  I'm just 
trying to distil the discussion down to as small a question as possible. :-)


Cheers.

--Larry Garfield

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Andrea Faulds]

Hi Larry,

Larry Garfield wrote:

The tricky part here is that saying a function does not return is not
something PHP currently does:

https://3v4l.org/HtAuC

No return implicitly returns NULL, which you can assign to a variable
if, for some strange reason, you were so inclined.  So this would be
more than "just" a syntactic documentation feature.


Which has been pointed out.


Which I believe gives the following options:

1) Change the language behavior such that

function foo() : void { ...}
$a = foo();

Is a syntax error (because there really was nothing returned to assign),
rather than resulting in $a having a value of NULL.


As the RFC notes, this breaks things, and is inconsistent with how PHP 
already does things.



2) Use null as a "type" (which I agree feels weird just saying it), such
that:

function foo() : null { ...}
$a = foo();

and

function foo() { ...}
$a = foo();

are identical.  The former would impact the contents of the function
(eg, a non-empty return would be a parse error), but the external result
is the same ($a == NULL).


This would be strange. The manual doesn't say `null`, and I can't think 
of any language which uses `null` as the return type in this situation, 
even when they have the same implicit-null-return behaviour that PHP has 
(see the email you're replying to).


Also, wouldn't you expect this to behave like existing type hints, and 
let you return a null value from any source? But that's not what you 
would actually want, right?


Thanks.

--
Andrea Faulds
http://ajf.me/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php