Hello, this is not much the syntax which is problematic here but the implicit lambda capture ruleset proposed; for that, it would require (fully justified in this case) a preprocessing step hence a language contextual analysis step or what people call `static`.
On Wed, Apr 10, 2019 at 2:35 AM Stephen Reay <php-li...@koalephant.com> wrote: > > > On 10 Apr 2019, at 15:59, Robert Hickman <robehick...@gmail.com> wrote: > > > >> I'd just like to amplify this mention of 3rd party tooling: if we go > with > >> something which requires complex lexer/parser rules, then every editor, > >> IDE, and static analysis tool will need to also work with that syntax. > >> > > > > Is this actually a problem? Don't these tools make use of existing > > parsers like 'php parser', thus the cost is lower than initially > > apparent? > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > This seems like a risky thing to assume “it’ll be fine” about. > > I’d like to add my (non-voting) voice in favour of the `fn(…)` syntax. I > don’t know that I’d get a lot of use out of short closures anyway, but I’d > at least like it to remain readable on the occasion I might use them, or > (more likely) work on something where someone else uses them. > > I question (loudly) any view that less characters is automatically > improves readability. I’ve yet to see a project anywhere that suffered > overrun or saw low productivity because developers were busy typing/reading > parenthesis around argument lists or keywords. > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
