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

RE: [PHP-DEV] [RFC] Void Return Type

[François Laupretre]

Hi,

 De : Andrea Faulds [mailto:a...@ajf.me]
  following codes  still works:
 
$b = a();
 
  so, if you want a void return type, and if you want it to be a useful
feature..
 
  above expr should be invalid with an error  a() return nothing
 
 I'm not sure about this. PHP has always made functions valid rvalues, for
 better or for worse. This RFC could make void functions truly void

What about renaming this hint to 'null', instead of 'void'. I know that it
supports no explicit return and 'return;' with no value but what it does is
more checking that return value is null, than checking return value is
'void', whose concept is not defined yet.

It would remove the ambiguity on the fact that the return value is used or
not. The only justification is that, in PHP, not returning an explicit
value, or using 'return;' returns null, that's history, period.

I think it would make the concept easier to understand and would reserve the
ambiguous 'void' keyword for the future, if it finds a utility one day.

Cheers

François



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

Re: [PHP-DEV] [RFC] Void Return Type

[Andrea Faulds]

Hey François,

On 14 Feb 2015, at 04:57, François Laupretre franc...@php.net wrote:

 That's a nice addition and a beginning to distinguish void from null, as I 
 imagine the function still returns null.
 
 Now, what about making void a real zval type ? It would open a lot of 
 possibilities. Unlike null, conversions from void would raise an error. It 
 would also be rejected as argument input type but could be used as an output 
 type when arg is passed by ref, it could be the default type for return_value 
 (huge BC break here) and so on...

We could do this, but for the longest time we've made all functions have some 
return value, even ones which don't explicitly return one (they return NULL). I 
think it'd be better not to change this. I expect IDEs and such could earn you 
about it, though.

 There's a need for a real 'no value' type different from null, as null has 
 too many uses. If defined correctly, it can be a powerful addition.

If I was to go back to 1994, I'd add undefined to PHP like JS has. Today, 
though, I think that is unrealistic, as much as I wish it wasn't. A void type 
only really makes sense as a pseudo-type for return type checking purposes, IMO.


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

Re: [PHP-DEV] [RFC] Void Return Type

[Andrea Faulds]

Hi,

 On 14 Feb 2015, at 03:32, reeze re...@php.net wrote:
 
 Do we really have to throw an catchable fatal error?
 
 the other return types make sense, why so strict?

We throw E_RECOVERABLE_ERROR for all type errors, both for parameters and 
return types. It's not anything new.

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

[Alain Williams]

On Sat, Feb 14, 2015 at 12:26:08PM +, Andrea Faulds wrote:

 We could do this, but for the longest time we've made all functions have some 
 return value, even ones which don't explicitly return one (they return NULL). 
 I think it'd be better not to change this. I expect IDEs and such could earn 
 you about it, though.

All *existing* functions have a return value. That would not change.

If someone makes one of their functions void then where they use it could not be
where a value is needed. So: expect it in new code; but in 5 years time that
code will be mature.

-- 
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT 
Lecturer.
+44 (0) 787 668 0256  http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: 
http://www.phcomp.co.uk/contact.php
#include std_disclaimer.h

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

Re: [PHP-DEV] [RFC] Void Return Type

[Andrea Faulds]

Hi,

 On 14 Feb 2015, at 05:03, Xinchen Hui larue...@php.net wrote:
 
 Hey:
 be honest, I think it's only part of the idea is implemented.
 
 which make it useless.
 
 in PHP, even if you don't return anything, NULL is returned implicitly.
 
 even if a function is declared return nothing(void).
 
 like:
 
   function a() : void {};
 
 following codes  still works:
 
   $b = a();
 
 so, if you want a void return type, and if you want it to be a useful 
 feature..
 
 above expr should be invalid with an error  a() return nothing

I'm not sure about this. PHP has always made functions valid rvalues, for 
better or for worse. This RFC could make void functions truly void, but that 
would be a massive change to support value-less function returns. It would also 
break existing code which assumes all functions return a value, which isn't 
good.

I think this RFC is enough: it would let you enforce that a function doesn't 
return anything and makes code more self-documenting. It doesn't affect 
anything trying to use the function's implicit return value of NULL, but IDEs 
and code linters would surely pick up on it for you. It's still useful even if 
it doesn't bind the caller.

Thanks.

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

Re: [PHP-DEV] [RFC] Void Return Type

[Andrea Faulds]

Hi,

 On 14 Feb 2015, at 05:54, Stanislav Malyshev smalys...@gmail.com wrote:
 
 Hi!
 
 I'm not sure what it is useful for, exactly. I mean, the more fatal
 errors the merrier, but I fail to see what exactly use except having yet
 more cases when your code may break it provides. I mean, if you defined
 a void function, that means you're not using it return value anywhere.
 Then who cares what return statement says?

What would be the point of *allowing* returning a value? It's clearly an error. 
We could let you return anything and then discard it, but now you won't spot 
the error in your code.

 Additionally, this RFC gets inheritance wrong - having return from
 function that previously did not return anything is not a violation of
 contract, since there's no practical contract that can rely on function
 not returning anything (in fact, there's no way in PHP to even check
 that AFAIK).

I am wondering about inheritance as well. I thought of void as having no 
subclass. But it's not really a return type for our purposes, it's more like a 
declaration that a function doesn't return anything.

So, I guess inheritance should allow removing or changing the typehint if it is 
void. I might need more opinions on this first, though.

 Summarily, this seems to me an exercise in strictness for the sake of
 strictness. There are languages that force people to abide by a lot of
 rules because their creators believe more rules is the same as better
 code, but PHP never was one of them and the fact there are so many
 people trying to make PHP that makes me sad.

It's not merely for the sake of it. It makes function signatures more 
descriptive, and lets you catch bugs in your code.

We already use void in the manual: why not in PHP?

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

[Stanislav Malyshev]

Hi!

 What would be the point of *allowing* returning a value? It's clearly

It's an error only because you declared it an error.

 an error. We could let you return anything and then discard it, but
 now you won't spot the error in your code.

Function return values which are going unused all the time. In PHP,
functions are very frequently called for side effects and not return
values. So returning value and discarding it is a common and perfectly
valid scenario. And it also has absolutely nothing to do with void
declaration - void declaration doesn't cause discarding the value and
you can discard the value with or without it.

 It's not merely for the sake of it. It makes function signatures more
 descriptive, and lets you catch bugs in your code.

Only bug it can catch is wrongly declaring the function to be void -
which is introduced by this RFC. For me, it is a clear case of
generating error for the sake of error.

 We already use void in the manual: why not in PHP?

Because the manual is the *documentation*, not code. It explains that
the function does not return anything useful. It's not the same as
creating an error when function returns something useful.
-- 
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

[Nikita Popov]

On Sat, Feb 14, 2015 at 3:28 PM, Stanislav Malyshev smalys...@gmail.com
wrote:

 Hi!

  What would be the point of *allowing* returning a value? It's clearly

 It's an error only because you declared it an error.

  an error. We could let you return anything and then discard it, but
  now you won't spot the error in your code.

 Function return values which are going unused all the time. In PHP,
 functions are very frequently called for side effects and not return
 values. So returning value and discarding it is a common and perfectly
 valid scenario. And it also has absolutely nothing to do with void
 declaration - void declaration doesn't cause discarding the value and
 you can discard the value with or without it.

  It's not merely for the sake of it. It makes function signatures more
  descriptive, and lets you catch bugs in your code.

 Only bug it can catch is wrongly declaring the function to be void -
 which is introduced by this RFC. For me, it is a clear case of
 generating error for the sake of error.

  We already use void in the manual: why not in PHP?

 Because the manual is the *documentation*, not code. It explains that
 the function does not return anything useful. It's not the same as
 creating an error when function returns something useful.


One of the primary purposes of having typehints *is* documentation. This
applies both to our existing type annotations, to the newly introduced
return declarations - and to the void return type. The advantage of having
the type declaration be part of the language (rather than a docblock) is
brevity on one hand and verification of its correctness on the other hand.
It's easy to forget to update docblock type annotations, but you can't get
away with specifying an incorrect language-supported annotations - if you
use a wrong type annotation your code just won't work.

The void return type is actually the one case where we can at compile-time
fully verify that it is used correctly - which is great.

Allowing to return a value from a void function doesn't make sense. If you
want to return a value, don't declare it as void. If you declare it as
void, don't return a value. It's really as simple as that.

Nikita

Re: [PHP-DEV] [RFC] Void Return Type

[Pierre Joye]

On Feb 14, 2015 6:28 AM, Stanislav Malyshev smalys...@gmail.com wrote:

 Hi!

  What would be the point of *allowing* returning a value? It's clearly

 It's an error only because you declared it an error.

  an error. We could let you return anything and then discard it, but
  now you won't spot the error in your code.

 Function return values which are going unused all the time. In PHP,
 functions are very frequently called for side effects and not return
 values. So returning value and discarding it is a common and perfectly
 valid scenario. And it also has absolutely nothing to do with void
 declaration - void declaration doesn't cause discarding the value and
 you can discard the value with or without it.

I have no strong opinion on the void but reading this exact comment makes
me think that there is clearly an issue here.

How ignoring values is a perfectly valid scenario? Yes, there are cases
where some code does not need it but it is clearly not clean nor correct.

  It's not merely for the sake of it. It makes function signatures more
  descriptive, and lets you catch bugs in your code.

 Only bug it can catch is wrongly declaring the function to be void -
 which is introduced by this RFC. For me, it is a clear case of
 generating error for the sake of error.

No. It makes clear about what happens and what should be expected. I see it
as a complement to the return type rfc.

  We already use void in the manual: why not in PHP?

 Because the manual is the *documentation*, not code. It explains that
 the function does not return anything useful. It's not the same as
 creating an error when function returns something useful.

I did not check the implementation yet but I suppose it does not default to
void, f.e. for existing codes. So I do not see about which errors you are
talking about here.

However yes, future codes (lib, apps, etc) using void will create this
error and it will be pretty easy to make the caller happy, no?

A common thing I see lately is to look at legacy code to consider what
should or can be php tomorrow. I consider it as a strategic mistake. I am
not saying we should drastically change php or force users to rely on new
paradigms. But we must provide features to make php relevant for a wider
audience. And it is possible to do it without making it less easy to use.
We had the same discussion about OO when we developed 5.0, see where we are
now. Stronger than ever.

Cheers,
Pierre

Re: [PHP-DEV] [RFC] Void Return Type

[Stanislav Malyshev]

Hi!

 One of the primary purposes of having typehints *is* documentation. This

Documentation causing fatal errors is something quite unusual. And wrong.

 applies both to our existing type annotations, to the newly introduced

That is not true, for existing types documentation is not the only and
not the primary purpose. Primary purpose is ensuring the method gets the
value it expects. Otherwise phpdoc would be enough.

 return declarations - and to the void return type. The advantage of
 having the type declaration be part of the language (rather than a
 docblock) is brevity on one hand and verification of its correctness on
 the other hand. It's easy to forget to update docblock type annotations

There's absolutely no brevity advantage and verification, as I
mentioned, in this case is not very useful.

 The void return type is actually the one case where we can at
 compile-time fully verify that it is used correctly - which is great.

No, you can not, since you have no idea how your function is used and
where.

 Allowing to return a value from a void function doesn't make sense. If

Having language-enforced concept of void function in PHP doesn't make
sense. PHP functions always return values, and verifying that function
pretends to not return value has no use, as no code can depend on it.

 you want to return a value, don't declare it as void. If you declare it
 as void, don't return a value. It's really as simple as that.

That's exactly kind of thing that makes me sad. Inviting rules in the
language that exist for their own sake and then saying well, you don't
like it, don't break the rules!
-- 
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

[Nikita Popov]

On Sat, Feb 14, 2015 at 6:03 AM, Xinchen Hui larue...@php.net wrote:

 Hey:



 On Sat, Feb 14, 2015 at 11:18 AM, Andrea Faulds a...@ajf.me wrote:
  Hi everyone,
 
  I’ve written a small RFC and patch to add a “void” return type:
 
  https://wiki.php.net/rfc/void_return_type
 
  Please have a read over it. I think this would be a simple, yet useful
 addition.
 be honest, I think it's only part of the idea is implemented.

 which make it useless.

 in PHP, even if you don't return anything, NULL is returned implicitly.

 even if a function is declared return nothing(void).

 like:

function a() : void {};

 following codes  still works:

$b = a();

 so, if you want a void return type, and if you want it to be a useful
 feature..

 above expr should be invalid with an error  a() return nothing

 so, I am -1 on this in complete RFC


Hi Xinchen!

While doing something like $b = a() where a() is a void function does not
make sense usually (and e.g. C will generate a warning/error for this) in
PHP there are some cases where you would want to use the return value of a
void function. Namely those are cases where you aren't calling a specific
function, but a callback that can return anything instead. E.g. consider
something like a partial application helper:

function bind($fn, ...$bindArgs) {
return function(...$args) use($fn) {
return $fn(...$bindArgs, ...$args);
};
}

Right now this would work no matter how $fn is declared. However if you
disallow using the return value of void functions, you'd have to create an
extra bindVoid() function which does exactly the same thing, just without
the return.

As such I don't think we can reasonably forbid using the return value of a
void function. The utility of the void return type in PHP would be
self-documenting function signatures. An IDE (or other static analyzer)
would of course detect cases where the return value of a void function is
used.

Nikita

AW: [PHP-DEV] [RFC] Void Return Type

[Robert Stoll]

Hi Andrea,

 -Ursprüngliche Nachricht-
 Von: Andrea Faulds [mailto:a...@ajf.me]
 Gesendet: Samstag, 14. Februar 2015 04:18
 An: PHP Internals
 Betreff: [PHP-DEV] [RFC] Void Return Type
 
 Hi everyone,
 
 I’ve written a small RFC and patch to add a “void” return type:
 
 https://wiki.php.net/rfc/void_return_type
 
 Please have a read over it. I think this would be a simple, yet useful 
 addition.
 
 Thanks!
 --
 Andrea Faulds
 http://ajf.me/
 
 
 
 
 
 --
 PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: 
 http://www.php.net/unsub.php

I think a void type for PHP would make sense but only if the return value of 
such a function cannot be used. 
Otherwise it is another reason for people to laugh at PHP and justifiably so, 
telling that a function does not return anything but return null is very 
inconsistent. 

I suggest to use one of the following behaviours:
1. declaring a function void does not return anything (hence is like echo to a 
certain agree)
2. declaring a function void does return a thing of type void (that would be 
similar to Unit in scala)
3. instead of void a function can be declared to be of type null - almost the 
same behaviour as your RFC but without the inconsistency

Cheers,
Robert


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

Re: [PHP-DEV] [RFC] Void Return Type

[Stanislav Malyshev]

Hi!

 How ignoring values is a perfectly valid scenario?

You are saying you're using return value for every function you're
calling, always? Please. How many times you used return value of sort()?
Every function with side effects can be used for its side effects, not
for its return value.

 new paradigms. But we must provide features to make php relevant for a
 wider audience. And it is possible to do it without making it less easy

This sounds like cargo cult, sorry - because other languages have
void, we have to have void and then their users would come to us.
That's exactly how cargo cult works - copying external appearances
without considering underlying processes. In PHP, there's no meaning to
void function except for self-enforcing documentation, and documentation
should be properly done by other means and should not produce fatal errors.

 to use. We had the same discussion about OO when we developed 5.0, see
 where we are now. Stronger than ever.

No, it's not like OO at all. OO is a huge conceptual framework with very
wide use and it can help with developing code and making people more
productive. Having void just helps with having void.
-- 
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

[Andrea Faulds]

Hi Robert,

 On 14 Feb 2015, at 21:23, Robert Stoll p...@tutteli.ch wrote:
 
 I think a void type for PHP would make sense but only if the return value of 
 such a function cannot be used.

Why? If the return value cannot be used, it prevents the function being used 
with any API that stores the return value of a callback. That’s not terribly 
nice.

A void return value doesn’t need to enforce anything on the caller. PHP has 
always filled in missing values with NULLs, including return values, like other 
dynamic languages do here.

 Otherwise it is another reason for people to laugh at PHP and justifiably so, 
 telling that a function does not return anything but return null is very 
 inconsistent.

It does implicitly return NULL, but NULL is a useless value, and it’s returned 
implicitly, rather than explicitly. I don’t think it’s really that ludicrous.

 I suggest to use one of the following behaviours:
 1. declaring a function void does not return anything (hence is like echo to 
 a certain agree)

That makes it cease to be a function in the PHP sense. PHP always allows 
functions to be used in expressions.

 2. declaring a function void does return a thing of type void (that would be 
 similar to Unit in scala)

We don’t need another form of NULL.

Also, a thing of type void could be passed around, just as the unit type can be 
in other languages, so it wouldn’t do what you want it to.

 3. instead of void a function can be declared to be of type null - almost 
 the same behaviour as your RFC but without the inconsistency

That seems like a strange solution. You’re requiring the function to always 
return a useless value.

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





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

AW: [PHP-DEV] [RFC] Void Return Type

[Robert Stoll]

 -Ursprüngliche Nachricht-
 Von: Andrea Faulds [mailto:a...@ajf.me]
 Gesendet: Samstag, 14. Februar 2015 22:38
 An: Robert Stoll
 Cc: PHP Internals
 Betreff: Re: [PHP-DEV] [RFC] Void Return Type
 
 Hi Robert,
 
  On 14 Feb 2015, at 21:23, Robert Stoll p...@tutteli.ch wrote:
 
  I think a void type for PHP would make sense but only if the return value 
  of such a function cannot be used.
 
 Why? 

I already mentioned why, because it is inconsistent. I see that you look at it 
from another point of view. Maybe I missed something but I figured the 
following function:

function foo(){}

is equivalent to 

function foo() {return;}

is equivalent to 

function foo() {return null;}

or am I wrong? Does it have a different behaviour?

If not, then still claim it is inconsistent. NULL is treated as own type in PHP 
(at least specs says so [1]) hence I do not see why null should be returned 
when the function is defined as void (but I would also be happy with the other 
suggestions below)
 
[1] 
https://github.com/php/php-langspec/blob/0f9985ba76ab7890a9a8440f8a4344c58f0a6761/spec/05-types.md#the-null-type

 If the return value cannot be used, it prevents the function being used with 
 any API that stores the return value of a callback. That’s not terribly nice.

No problem to wrap such a function into another callback returning null. It was 
not defined with void for no reason, that is how I look at it.

 
 A void return value doesn’t need to enforce anything on the caller. PHP has 
 always filled in missing values with NULLs,
 including return values, like other dynamic languages do here.

In what other cases does PHP fill in missing values with NULLs (expect from 
return type and collection initialisation, that is something different IMO)?


 
  Otherwise it is another reason for people to laugh at PHP and justifiably 
  so, telling that a function does not return
 anything but return null is very inconsistent.
 
 It does implicitly return NULL, but NULL is a useless value, and it’s 
 returned implicitly, rather than explicitly. I don’t think it’s
 really that ludicrous.

How dare you calling NULL useless :P 

Might be that other do not think it is inconsistent. For me it does not make a 
difference if something is returned explicitly or implicitly, in the end it 
still returns something and this something needs to be of the type the return 
type hint claims to be. That is what I define consistent.
I could live with the idea of void as alias for null (or abstract parent type 
of null if you do not like an alias) but otherwise, why should the following 
not be allowed:

function foo : void { return null;}

when it is returned anyway if I omit the statement?

 
  I suggest to use one of the following behaviours:
  1. declaring a function void does not return anything (hence is like
  echo to a certain agree)
 
 That makes it cease to be a function in the PHP sense. PHP always allows 
 functions to be used in expressions.

Sure, every function which returns something (explicitly or implicitly) can be 
used in an expression. If void defines to return nothing, then it could not be 
used in an expression. I do not see a problem here, no rather the other way 
round. Consider the following example:

function foo() : void {}
$b = foo() + 1; //I would like to see an error here rather that 1 is assigned 
to $b

 
  2. declaring a function void does return a thing of type void (that
  would be similar to Unit in scala)
 
 We don’t need another form of NULL.
 
 Also, a thing of type void could be passed around, just as the unit type can 
 be in other languages, so it wouldn’t do what
 you want it to.

Of course it would. void could be defined in such a way that it does not 
support implicit conversions to other types. Taking the example from above the 
following would result in an error as well:

function foo() : void {}
$b = foo() + 1; //would emit an error Unsupported operand types for + like it 
is done for: new Exception() + 1;

And as someone else on the list already mentioned such an approach would allow 
other features.

 
  3. instead of void a function can be declared to be of type null -
  almost the same behaviour as your RFC but without the inconsistency
 
 That seems like a strange solution. You’re requiring the function to always 
 return a useless value.

Yes, that is what already happens anyway. You look at it from the wrong point 
of view IMO, you did not consider the implicit return to be similar to implicit 
conversions respectively.  A user would not be required to write a return 
statement like a user is not required to cast an int value to string when 
passed to an internal function which expects string. If you think in this terms 
then it makes absolutely sense to state that a function returns null.

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



--
PHP Internals - PHP Runtime

Re: [PHP-DEV] [RFC] Void Return Type

[Alain Williams]

On Sat, Feb 14, 2015 at 01:03:44PM +0800, Xinchen Hui wrote:

function a() : void {};
 
 following codes  still works:
 
$b = a();
 
 so, if you want a void return type, and if you want it to be a useful 
 feature..
 
 above expr should be invalid with an error  a() return nothing

+1 - my first thought.

-- 
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT 
Lecturer.
+44 (0) 787 668 0256  http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: 
http://www.phcomp.co.uk/contact.php
#include std_disclaimer.h

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

RE: [PHP-DEV] [RFC] Void Return Type

[François Laupretre]

 De : Andrea Faulds [mailto:a...@ajf.me]
 I’ve written a small RFC and patch to add a “void” return type:
 
 https://wiki.php.net/rfc/void_return_type
 
 Please have a read over it. I think this would be a simple, yet useful 
 addition.

That's a nice addition and a beginning to distinguish void from null, as I 
imagine the function still returns null.

Now, what about making void a real zval type ? It would open a lot of 
possibilities. Unlike null, conversions from void would raise an error. It 
would also be rejected as argument input type but could be used as an output 
type when arg is passed by ref, it could be the default type for return_value 
(huge BC break here) and so on...

There's a need for a real 'no value' type different from null, as null has too 
many uses. If defined correctly, it can be a powerful addition.

François


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

Re: [PHP-DEV] [RFC] Void Return Type

[Xinchen Hui]

Hey:



On Sat, Feb 14, 2015 at 11:18 AM, Andrea Faulds a...@ajf.me wrote:
 Hi everyone,

 I’ve written a small RFC and patch to add a “void” return type:

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

 Please have a read over it. I think this would be a simple, yet useful 
 addition.
be honest, I think it's only part of the idea is implemented.

which make it useless.

in PHP, even if you don't return anything, NULL is returned implicitly.

even if a function is declared return nothing(void).

like:

   function a() : void {};

following codes  still works:

   $b = a();

so, if you want a void return type, and if you want it to be a useful feature..

above expr should be invalid with an error  a() return nothing

so, I am -1 on this in complete RFC

thanks

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





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




-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV] [RFC] Void Return Type

[reeze]

HI,

On 14 February 2015 at 12:57, François Laupretre franc...@php.net wrote:

  De : Andrea Faulds [mailto:a...@ajf.me]
  I've written a small RFC and patch to add a void return type:
 
  https://wiki.php.net/rfc/void_return_type
 
  Please have a read over it. I think this would be a simple, yet useful
 addition.

 That's a nice addition and a beginning to distinguish void from null, as I
 imagine the function still returns null.

 Now, what about making void a real zval type ? It would open a lot of
 possibilities. Unlike null, conversions from void would raise an error. It
 would also be rejected as argument input type but could be used as an
 output type when arg is

passed by ref, it could be the default type for return_value (huge BC break
 here) and so on...

 There's a need for a real 'no value' type different from null, as null has
 too many uses. If defined correctly, it can be a powerful addition.


What is the benefit of passing a void value around just for return type?
and the rest of engine will have to take care of IS_VOID type,
it seems doesn't worth it.



 François


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




-- 
Reeze Xia
http://reeze.cn

Re: [PHP-DEV] [RFC] Void Return Type

[Stanislav Malyshev]

Hi!

 I’ve written a small RFC and patch to add a “void” return type:
 
 https://wiki.php.net/rfc/void_return_type
 
 Please have a read over it. I think this would be a simple, yet useful 
 addition.

I'm not sure what it is useful for, exactly. I mean, the more fatal
errors the merrier, but I fail to see what exactly use except having yet
more cases when your code may break it provides. I mean, if you defined
a void function, that means you're not using it return value anywhere.
Then who cares what return statement says? If you _are_ using its return
value, then a) why you declared it as void and b) how comes you expect
return value from a function that is supposed to always return null?

Additionally, this RFC gets inheritance wrong - having return from
function that previously did not return anything is not a violation of
contract, since there's no practical contract that can rely on function
not returning anything (in fact, there's no way in PHP to even check
that AFAIK).

Summarily, this seems to me an exercise in strictness for the sake of
strictness. There are languages that force people to abide by a lot of
rules because their creators believe more rules is the same as better
code, but PHP never was one of them and the fact there are so many
people trying to make PHP that makes me sad.
-- 
Stas Malyshev
smalys...@gmail.com

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

[PHP-DEV] [RFC] Void Return Type

[Andrea Faulds]

Hi everyone,

I’ve written a small RFC and patch to add a “void” return type:

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

Please have a read over it. I think this would be a simple, yet useful addition.

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

[reeze]

Do we really have to throw an catchable fatal error?

the other return types make sense, why so strict?

On 14 February 2015 at 11:18, Andrea Faulds a...@ajf.me wrote:

 Hi everyone,

 I've written a small RFC and patch to add a void return type:

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

 Please have a read over it. I think this would be a simple, yet useful
 addition.

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





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




-- 
Reeze Xia
http://reeze.cn