Re: [RFC] Support for <func>::function syntax

On Sat, Nov 7, 2020, at 5:41 PM, as@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