On Sat, Nov 7, 2020, at 5:41 PM, a...@php.net wrote: > Hello internals, > > Looking for feedback on the idea of supporting `::function` syntax (or > `::fn`) for consistency with existing `::class` syntax: > > $arr = ['apple']; > print_r(array_map(strtoupper::function, $arr)); > > (Apologies if this has already been discussed. Hard to search for > colon-colon-function.) > > Benefits in my view are readability and potential use in static analysis. > Downsides (as implemented in proof-of-concept) are that it can be > needlessly littered in a lot of places, and that it breaks class consts > named `function`. I'd vote against it in its current state, but if people > like the general idea maybe the drawbacks can be addressed with a better > implementation. > > Examples: > https://gist.github.com/adsr/2c0b9243986418af3cecf8046657304b > > Proof-of-concept: > https://github.com/adsr/php-src/commit/07bb24243022ccef5823f6977d231f3535a48a07.patch > > Adam
There was some discussion earlier this year, although if memory serves it was in a thread whose name would not be helpful for searching. Sorry, can't help there. :-/ (Maybe it was in the threads talking about ::class notation on objects? Just a guess.) Working strictly from memory: * There was a lot of support in concept, but not universal. * There was a lot of concern that ::function was just too damned long to type, so plenty of bikeshedding about shorter names. * There's another RFC proposed that is currently stalled due to lack of time to add partial function application, which would kinda allow something similar-ish through a back door: https://wiki.php.net/rfc/partial_function_application . That said, I don't think they would conflict so I'd be fine with both happening. +1 from me in concept. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
