On 22 February 2020 06:50:46 GMT+00:00, Mike Schinkel <m...@newclarity.net> wrote: >> On Feb 21, 2020, at 5:20 PM, Rowan Tommins <rowan.coll...@gmail.com> >wrote: >> 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."
Perhaps, yes. I freely admit it's an emotional reaction rather than a rational one. >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. Maybe. I think a larger part of it is that references themselves are a slightly confusing concept, and the fact that & looks like an operator of its own (and is often documented that way) but is really an annotation on other operators/commands. That is, the & in $foo = &$bar and return &$bar doesn't modify $bar, it modifies = and return, respectively. Making the rules more logical and symmetrical would perhaps be more helpful to new users than it is to established users, particularly those who've known multiple versions of the language already. > 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? The concern is that the costs will be much more visible to users than the benefits, and they will resent the core developers pushing that requirement onto them, rather than thanking then for their hard work. As I said, that's not an absolute reason not to do it, it's a cost to be weighed. >> 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 > >So what specific problems would having these enhancement cause for the >language? There are two problems I have with internal-only features in general: the inability to polyfill and extend, and the requirement for a separate mental model. As an example of the first, the RFC mentions using call_user_func with a call-site annotation to forward the parameter by reference. The reason for allowing that also applies to a user-defined wrapper like call_with_current_user or call_with_swapped_parameters, but there's no syntax for those to be marked "prefer-val". As an example of the second, even under strict settings, calls to certain internal functions will have an optional & at the call site, which changes their behaviour. To those without knowledge of the core, those functions simply have to be remembered as "magic", because their behaviour can't be modelled as part of the normal 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. No, it's preferring to hold out for a little bit more value to weigh against my evaluation of the cost. This is, when followed through to its conclusion of mandatory marking, a disruptive change to every piece of code, so we need to decide if the disruption is worth it. It's also the second change in the same place, and we should be sure that we've got it right this time, and won't require a third change in the near future. For instance, if out parameters were added, would the same line of code end up going from optional &, to forbidden &, to mandatory &, to mandatory "out"? I'm not strongly against the idea, but the advantages just don't feel quite strong enough, so if I had a vote, I'd currently be inclined to vote no. Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
