Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion spec/09-lexical-structure.md
Original file line number Diff line number Diff line change
Expand Up @@ -269,7 +269,7 @@ Unless stated otherwise ([functions](13-functions.md#function-definitions),

Names beginning with two underscores (__) are reserved by the PHP language and should not be defined by the user code.

The following names cannot be used as the names of classes, interfaces, or traits: `bool`, `FALSE`, `float`, `int`, `NULL`, `string`, and `TRUE`.
The following names cannot be used as the names of classes, interfaces, or traits: `bool`, `FALSE`, `float`, `int`, `NULL`, `string`, `TRUE` and `void`.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Oxford comma went missing here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, yeah, my bad. Luckily it doesn't make a difference here, though.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@GrahamCampbell I've fixed it: 1935a4b

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I already sent a PR though: #151.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops, sorry. I guess it'll have to be closed now D:


The following names are reserved for future use and should not be used as the names of classes, interfaces, or traits: `mixed`, `numeric`, `object`, and `resource`.

Expand Down
4 changes: 4 additions & 0 deletions spec/11-statements.md
Original file line number Diff line number Diff line change
Expand Up @@ -903,6 +903,10 @@ by value or byRef. If *expression* is omitted the value `NULL` is used.
If execution flows into the closing brace (`}`) of a function, `return
NULL;` is implied.

Explicit `return` statements with *expression* given are not permitted within a
function with a `void` [return type](13-functions.md#return-typing) and MUST
cause a compile-time fatal error.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is the only part of the spec that mentions "compile-time fatal error" aside from the definition of E_COMPILE_ERROR. Is this the best way to express it? I'm trying to make it clear that this error doesn't occur when return is executed, but rather when the statement is encountered when parsing or compiling.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, is "Explicit return" clear enough, or do I need to clarify directly that this error doesn't happen for the implicit return NULL?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could make it clear that return; is fine, but like the implicit return at the end of the function, this is surely obvious.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Small correction: the spec is written in descriptive mode ("causes fatal error" rather than "MUST cause fatal error").

Otherwise, it looks clear enough.


A function may have any number of `return` statements, whose returned
values may have different types.

Expand Down
4 changes: 4 additions & 0 deletions spec/13-functions.md
Original file line number Diff line number Diff line change
Expand Up @@ -74,6 +74,7 @@ A function is called via the function-call operator [`()`](10-expressions.md#fun

<i>return-type:</i>
: <i>type-declaration</i>
: void
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This grammar isn't representative of how PHP actually implements this (making it be part of type-declaration and then throwing an error in the compiler if you use it as a parameter type). Should it be?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No I think it's fine - void is valid only as return type, not any type declaration.


<i>type-declaration:</i>
array
Expand Down Expand Up @@ -185,6 +186,9 @@ be compatible with the defined type, using the same rules as for parameter type
are not allowed for typed returns. If the value of the [`return` statement](11-statements.md#the-return-statement)
does not pass the type check, a fatal error is produced.

The `void` type is a special type that can only be used as a return type, and
not in other contexts. It has no effect at runtime, see the [`return` statement](11-statements.md#the-return-statement).

## Type check modes

The type checking can be performed in two modes, strict and coercive (default).
Expand Down
1 change: 1 addition & 0 deletions spec/19-grammar.md
Original file line number Diff line number Diff line change
Expand Up @@ -1035,6 +1035,7 @@ The grammar notation is described in [Grammars section](09-lexical-structure.md#

<i>return-type:</i>
: <i>type-declaration</i>
: void

<i>type-declaration:</i>
array
Expand Down
20 changes: 20 additions & 0 deletions tests/functions/void_allowed.phpt
Original file line number Diff line number Diff line change
@@ -0,0 +1,20 @@
--TEST--
void return type: acceptable cases
--FILE--
<?php

function foo(): void {
// okay
}

foo();

function bar(): void {
return; // okay
}

bar();

echo "OK!", PHP_EOL;
--EXPECT--
OK!
12 changes: 12 additions & 0 deletions tests/functions/void_disallowed1.phpt
Original file line number Diff line number Diff line change
@@ -0,0 +1,12 @@
--TEST--
void return type: unacceptable cases: explicit NULL return
--FILE--
<?php

function foo(): void {
return NULL; // not permitted in a void function
}

// Note the lack of function call: function validated at compile-time
--EXPECTF--
Fatal error: A void function must not return a value in %s on line %d
12 changes: 12 additions & 0 deletions tests/functions/void_disallowed2.phpt
Original file line number Diff line number Diff line change
@@ -0,0 +1,12 @@
--TEST--
void return type: unacceptable cases: explicit return of some other value
--FILE--
<?php

function foo(): void {
return -1; // not permitted in a void function
}

// Note the lack of function call: function validated at compile-time
--EXPECTF--
Fatal error: A void function must not return a value in %s on line %d
8 changes: 8 additions & 0 deletions tests/functions/void_parameter.phpt
Original file line number Diff line number Diff line change
@@ -0,0 +1,8 @@
--TEST--
void return type: not valid as a parameter type
--FILE--
<?php

function foobar(void $a) {}
--EXPECTF--
Fatal error: void cannot be used as a parameter type in %s on line %d
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if this test should be included, since a reasonable implementation might consider this a syntax error.

(Also, should we really be testing error messages anyway? They're not in the spec. :/)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, not really, we could rewrite the tests to only check if there's exception now. If anybody has the time ;)