It's a common thing to want to introduce a new keyword as a reserved
word as part of an RFC.
(Recently: match, mixed, guard, readonly...)
These new keywords always lead to possible BC breaking changes because
they become unusable for namespaces, class names, function names and
This may sound frivolous, but has it been considered to try to find a
way to make it possible to have some classes of language keywords and
identical class names etc. living side by side?
One thing I could think of is to allow prefixing either new keywords
or conflicting class names with a special character whenever there is
a possibility of ambiguity in the syntax.
Let's take an example - I've always wanted to name a class "Function"
:-) It would live in a namespace, f.ex. \App\Middleware\Function. I
don't really see how declaring the class Function or using the fully
qualified class name could be an insurmountable obstacle to
distinguish from the keyword used to declare a function.
However, if you're already in the \App\Middleware namespace and just
find the untethered Function in the code, that would not be nice to
the parser. But if we prefixed it with .\Function the confusion would
evaporate, wouldn't it?
This idea would not eliminate this kind of Backward Incompatible
Changes but the upgrade path to simply prefix the class name etc. with
.\ or something else, whenever it was found out and alone, would cause
a lot less friction that renaming files and classes. And as such it
just might lead to more, otherwise nice RFC's being accepted :-)
If this sparks some interest, let me know. Or rather, tell me please
in a mild tone why this would be a total disaster.