On 06/10/2022 12:16, Alex Wells wrote:
A marker merely just tells the compiler "hey, allow me to use this feature right here", i.e. it denotes a piece of code as allowed to use the feature, not enable it. Effectively, all experimental features are just regular features that are "always on" and hence can be optimized the same way regular features are. The marker serves two purposes: allow simple discovery of usages (by the compiler or other tools) and force the developer to acknowledge they're using an experimental feature with an unstable API/syntax/spec.
I don't really understand the distinction between "enabling" and "being able to use", nor what it would mean for a feature to "experimental" but also integrated fully into the language.
In general, I'm finding it quite hard to follow the idea in the abstract - the definition of "feature" seems very fuzzy. Could someone give some examples from another language, or concrete examples where it would be used in PHP, and then work through the details of what would be expected to happen in what version of PHP?
Regarding the monitoring - that is a problem that needs to be solved and there are multiple solutions: GitHub issues, corporate/public messengers (Slack?) or the internals mailing list.
There are certainly ways to approach it; I'm just agreeing with a previous commenter that this would need to be an explicit part of any proposal, not just hand-waved away.
Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
