There is some confusion here: A valid name is made up of any string, not
just strings that are identifiers.
Example of use of a variable named "+!" (...)
Of course, names that are not identifiers cannot appear in constructs that
accept an identifier only, such as an extends clause.
You are right, and I have been sloppy about it throughout this thread.
PHP does distinguish the two: an identifier is a lexical token the scanner
produces from source text, a name is whatever string ends up in a symbol
table, and the second set is much larger than the first. Your ${'+!'} and
the empty-string class alias make that concrete in a way my wording did
not.
That distinction helps the proposal rather than undermining it. What I am
describing governs identifiers only. Names created at run time through
$$name, define(), class_alias() or json_decode() are untouched -- and that
is not a gap I invented to make the scope convenient, it is a line PHP
already draws and enforces syntactically, exactly as you say with
extends. Juliette raised the same question from the other side in
another subthread; I will answer her with your terminology rather than
mine.
I will fix the wording in the draft.
I don't think that a per-file declare is a reasonable option. I would love
if the PHP compiler could complain with a clearer error whenever I type
accidentally a non-breaking space. But I wouldn't add a declare clause at
the top of each and every file just for that.
You are the third person to push back on the declare. Larry asked why it
is optional at all, and Rowan is circling the same ground from the
direction of rejecting versus normalising. Three people arriving there
independently is a signal, and I am no longer confident the declare is the
right vehicle.
What you describe wanting is also narrower than what I proposed, and the
two come apart cleanly. A rule that *rejects* has to be opt-in: the
5,000-package survey turned up a live, maintained library whose variable
names are mathematical formulae, which a mandatory rule would break 888
times. A diagnostic that *warns* about an accidental invisible character
needs no opt-in at all, and would catch your no-break space without asking
anything of you.
I would rather not choose between those in a reply. Rowan has asked me to
state the problem before the solution, which is fair, and your message is
evidence for the same point -- I started from a mechanism and have been
arguing backwards from it ever since. Let me answer him properly first,
and then come back to whether a declare is what any of this actually
needs.
Regards,
Luca