PHP 5 behavior when trying to instantiate a reserved word, such as "new return", "new class" or so, is a parse error :

Parse Error: syntax error, unexpected 'class' (T_CLASS)

So IMHO we should :

A) stick to that behavior and trigger a parse error
B) create a new error message for all reserved word usage attempt.

I vote A.

It seems ok to me raising E_ERROR for non defined classes and raising E_ERROR for non language instruction keywords. (Strictly speaking, "string" class is not parse error, but soft limitation)

http://php.net/manual/en/reserved.keywords.php
does not mention new "string"/etc keywords. I'll make this report as Documentation problem.

[yohgaki@dev PHP-7.0]$ ./php-bin 
<?php
class string{}
?>

Fatal error: Cannot use 'string' as class name as it is reserved in - on line 2
[yohgaki@dev PHP-7.0]$ ./php-bin 
<?php
class int{}
?>


Fatal error: Cannot use 'int' as class name as it is reserved in - on line 2




[yohgaki@dev PHP-7.0]$ php -v
PHP 5.6.15 (cli) (built: Oct 29 2015 15:24:09) 
Copyright (c) 1997-2015 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2015 Zend Technologies
    with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2015, by Zend Technologies
[yohgaki@dev PHP-7.0]$ php
<?php
class while{}
?>


PHP Parse error:  syntax error, unexpected 'while' (T_WHILE), expecting identifier (T_STRING) in - on line 2

yohgaki wrote:
> http://php.net/manual/en/reserved.keywords.php
> does not mention new "string"/etc keywords. I'll make this
> report as Documentation problem.

Type names (`string` etc.) are not proper keywords, but rather
reserved names and already listed as such[1]. Therefore this issue
is not a documentation issue.

jonathan dot massuchetti at gmail dot com wrote:
> A) stick to that behavior and trigger a parse error

Please note the difference between proper keywords and reserved
words. The former will trigger parse errord when used in
(syntactically) invalid contexts, but, IMHO rightly so, not the
latter. For instance, it's possible to use `string` as name of a
user defined function[2].

[1] <http://php.net/manual/en/reserved.other-reserved-words.php>
[2] <https://3v4l.org/IR9Hq>

This is a feature request, not a bug, or a documentation problem.

Making something that results in an exception (like new string;), result in a fatal error (which is what compiler errors are) has BC implications.

You might suggest that we don't raise a compiler error, and wait until runtime to raise an exception: In that case, why do some uses of reserved names result in errors and others in exceptions ?

These kinds of issues cannot be resolved by discussion on this issue tracker.

Please see: https://wiki.php.net/rfc/howto

@krakjoe : I understand your point. The author of the "bug" ask for a message change, not a error type change. 

The throwable Error for a class not found would need to check if the class requested is a reserved name, to update the error message.

While it is a feature request, it doesn't deserve an RFC.