On 23/12/2025 12:26, Sergei Issaev wrote:
However, I’d like to gently push back on two points:
1. <?~ vs <? (~$expr) under short_open_tag=On
You're correct that with short_open_tag=1, <?~ $x ?> would currently be
parsed as <? (~$x) ?>. But in practice:
- short_open_tag has been disabled by default since PHP 5.4 (2012).
But there is no plan to remove them, see
https://wiki.php.net/rfc/deprecate_php_short_tags_v2
https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags
- Most modern frameworks and coding standards explicitly discourage its
use.
Since they are still a valid code, so PHP and various coding standard
tools must parse them correctly.
- The <?= short echo tag is always available regardless of
short_open_tag, precisely because it’s treated specially.
If the RFC were to propose <?~ as a new short echo variant (like <?=),
it would follow the same rule: always enabled, independent of
short_open_tag. That would eliminate the ambiguity you mentioned.
No it doesn't. The grammar should stay consistent for every possible ini
state. I have a feeling that the tokenizer won't even compile with this
syntax. (not sure)
2. Why not just use h()?
Yes, h() works — and many projects already define it. But that’s exactly
the problem: everyone reinvents it, often with slightly different flags,
encoding assumptions, or error handling. This leads to:
- Inconsistent escaping across projects or even within the same codebase.
- Junior developers skipping escaping because “it’s not built in”.
- Security relying on project-specific conventions rather than language-
level defaults.
That also leads to a tailored experience suitable for a specific project
and context. I also don't see an inconsistent escaping as a huge problem
as long as it does its job.
By providing a standard, secure-by-default output tag in core, PHP would:
- Reduce boilerplate.
- Encourage safer habits out of the box.
- Give small projects (e.g., WordPress plugins, scripts, internal tools)
a zero-dependency way to escape safely — without requiring them to
define or remember h().
Secure today does not mean secure tomorrow. With the existing function
you can simply update the default flag set, or users can update their
flag sets ahead of PHP. For the syntax approach to be as flexible, it
needs to be configurable by some global state (set_escape_flags()? ini
config?) which is also a big no-no, that would be magic quotes all over
again, just slightly more explicit.
Magic quotes btw should be a lesson that you can't make stuff secure by
a simple all size fits all solution.
Think of it like <?= ... ?>: it didn’t add new capability, but it made
the common case easier and more consistent. <?~ ... ?> aims to do the
same for secure output.
<?= exists since forever and "= $expr" is not a valid code. You should
at least choose another symbol (like "<?*")
That said, I hear your concern about hardcoded flags. If the community
prefers, the escaping behavior could even respect default_charset and a
new html_output_flags ini setting — though I’d argue opinionated
security defaults are better here.
See above, also respecting default_charset is a must imho, not everyone
uses UTF-8, East Asia specifically. Introducing a core syntax and
excluding a huge portion of users is not a good move.
--
Anton
