Should hash comments be deprecated?

Hi,

Theodore Brown wrote:

Hi internals,

Since the #[] attribute syntax is currently winning the vote, 1
it makes me wonder if the use of comments starting with # should be
deprecated.

Otherwise it seems like we could be setting ourselves up for long-term
confusion between attributes and comments, and also inconsistency with
other comments (it will no longer be safe to assume that a line can be
commented out by simply adding # at the beginning).

What do others think?

Theodore

There is a critical use-case for comments beginning with the hash
symbol, namely UNIX shebang lines. In theory we could special-case those
and disallow the symbol in every other use, but… well, that seems like a
bit of a shame.

Regards,
Andrea

Hi Theodore,

Since the #[] attribute syntax is currently winning the vote, [1]
it makes me wonder if the use of comments starting with # should be
deprecated.

Otherwise it seems like we could be setting ourselves up for long-term
confusion between attributes and comments, and also inconsistency with
other comments (it will no longer be safe to assume that a line can be
commented out by simply adding # at the beginning).

What do others think?

I don't use # comments in practice that much, and objected to #[,
but I'd imagine there'd be two main objections.

1. Most significantly, existing code would break in the major version where the deprecation became an error.
   So libraries that stopped being maintained in 2020 or earlier would all either need to be forked (and forks would have to be published to composer), locally checked in,
   be affected by a post-install script, etc - non-technical users of PHP applications may not do that and delay upgrade to php 9.0 or 10.0.

   I imagine there may be very strong objections to that from others, but may be wrong, since the invalid # comments would be easy to check for and automatically fix.

2. Now that we're probably going to reuse #<rest> for one thing, we may end up using it for other things that would benefit from forwards compatibility
   now that applications are already forced to deal with this lexing change.

Some examples of what php developers hypothetically could do by continuing to repurpose #.
(I have no plans to put any of these forward as RFC)

declare(
    strict_types = 1,
    #php8.1 very_strict_something = 1 // #php8.1 could be a token that's treated like the end of a comment in php 8.1+
)

#[attribute] function() {/*unused closure*/}; some new php81_syntax();
// a more concise, self-explanatory version of the above that could be used in more places.
#php8.1 some new php81_syntax();

// A version of assert that is guaranteed not to throw with any ini settings
// and that can be optimized out in php.ini-production
#expect($condition);

// Adding a forward compatible syntax to declare that an argument is passed by reference
// i.e. https://wiki.php.net/rfc/explicit_send_by_ref
function inc(&$i) { $i++; }

// instead of 
inc(&$i);

// one of these could also be done
inc(/* & */$i);
inc(
    // or #byref
    #& 
    $i
);

Regards,

• Tyson

Since the #[] attribute syntax is currently winning the vote, [1]
it makes me wonder if the use of comments starting with # should be
deprecated.

I've mentioned this myself in R11 a few times and was planning on
bringing this up to a vote myself as soon as we started for 8.1

I think it makes perfect sense, there's no reason why we need both //
and # and if #[] wins out as it looks like it will, that's even more
reason to deprecate #.

There's an easy upgrade path too with a perfect substitution, and so far
as I can tell the only breakage would be if people were using external
code to do pre-processor like operations such as using #start and #end
as quasi-tags.

Ideally, if we pass #[ ] we would deprecate # in the same version and
put it on the fast-track to removal, but that would require an
additional vote.

Mark Randall

Hi internals,

If it turns out that the impact on legacy applications, legacy libraries, or holding back upgrades is a concern for others
(I'm not sure what the most common opinion is),
another option would be a system ini setting

hash_comment = 0|1|2
0 - disable #comment support completely when parsing/lexing - throw a ParseError while lexing and return T_ERROR in token_get_all
1 - (default) emit a compilation warning or deprecation notice when parsing files mentioning that hash comments will be removed in a future major release. Do this only for the first comment.
2 - allow it silently (possibly an unnecessary option to provide)

Then, this could be gradually strictened

• Forbid option 2 in php 8.x
• change the default ini setting value to 0 in 8.x or 9.0
• Add a configuration setting in php 8.x or 9.x to always disable hash comments
• Remove support

 Correct me if I'm wrong, but the shebang goes before the PHP opening
tag <?php and thus this is not relevant. In fact, shebang is already a
special case.

Yes, shebang can only be parsed on the first line of a script - before <?php sections.

Thanks,

• Tyson