> On Feb 21, 2020, at 5:20 PM, Rowan Tommins <rowan.coll...@gmail.com> wrote: > > On 20 February 2020 14:13:58 GMT+00:00, Nikita Popov <nikita....@gmail.com> > wrote: >> Hi internals, >> >> I'd like to start the discussion on the "explicit call-site >> pass-by-reference" RFC again: >> https://wiki.php.net/rfc/explicit_send_by_ref > > My instinctive reaction is still one of frustration that the pain of removing > call-site ampersands was in vain, and I will now be asked to put most of them > back in.
That is a great example of what is known as a "sunken cost." In summary "A a sunken cost is a cost paid in the past that is no longer relevant to decisions about the future." > It's also relevant that users already find where & should and should not be > used very confusing. One of the reasons it is confusing is because developers are currently required to use the ampersand in one place and not the other. Making it always used removes said confusion as they would no longer be a reason to have to remember when and when not to use the ampersand anymore. > There is a potential "PR" cost of this change that should be weighed against > the advantages. To say "We fixed something that in hindsight we've since determined was a problem." How is this a concern? And when has the PHP community primarily worried about PR cost anyway, except with Hack starting eating PHP's lunch in terms of performance? > I'm also not very keen on internal functions being able to do things that > can't be replicated on userland, and this RFC adds two: additional behaviour > for existing "prefer-ref" arguments, and new "prefer-value" arguments. I used to have the same preference. And then I realized that languages that allow everything and do not withhold low-level functionality allows userland to create of DSL-like extensions that can result in highly fragile and obtuse architectures. Just look at Ruby. And yes that is an abstraction, but so is a generic concern about adding internal functions that cannot be leveraged in userland. So what specific problems would having these enhancement cause for the language? > My current opinion is that I'd rather wait for the details of out and inout > parameters to be worked out, and reap higher gains for the same cost. For > instance, if preg_match could mark $matches as "out", I'd be more happy to > run in a mode where I needed to add a call-site keyword. This sounds like preferring perfect in the (potentially distant) future vs. much better today. If this feature does not block some abstract vision for a perfect future and is something that can be delivered in the short term to solve real-world problems today, why stand in its way? -Mike
