Re: [RFC] Explicit call-site pass-by-reference (again)

> On Feb 23, 2020, at 9:23 AM, Rowan Tommins <rowan.collins@gmail.com> wrote: > > Hi Mike, > > First, I'd just like to reiterate that I absolutely see benefits in this proposal, and am > definitely not campaigning for it to be abandoned as a bad idea. Like with any proposal, we have to > weigh those benefits against the costs, and my current personal opinion is that the scales come down > *very slightly* on the cost side. > > I will also just say that you have made some valid points about different ways people might > perceive this change, and my fears on that score may be overblown. > > > On 23/02/2020 07:03, Mike Schinkel wrote: > >> The RFC does not require mandatory use, period. >> >> The "cost" you worry about will not exist unless and until a future RFC proposes >> to make it mandatory and that RFC is accepted. > > The RFC states very clearly that the full benefit of the change will only be realised by making > the markers mandatory in some way, and includes specific discussion of how that might be introduced. > Put simply, tools (and even humans) get most from knowing that a particular line of code > *won't* pass anything by reference, and optional markers can't guarantee that. Fair point. > > I am analysing the proposal on that basis, just as I would analyse a proposed deprecation on > the basis that the deprecated feature will one day be removed. > > If we analyse it on the basis of it *never* becoming mandatory, we have to adjust our analysis > of both costs *and* benefits. However, if you consider editions, it may not ever need to become mandatory and yet those who want it could still benefit. > Regarding prefer-ref and prefer-val: > >> function call_with_current_user(Callable $callable, int &$foo, int $bar ) { >> return call_user_func( $callable, current_user(), &$foo, $bar ); >> } > > > If you define the function this way, all callers are *required* to pass the parameter by > reference. That immediately means that this is a fatal error: > > call_with_current_user('foobar', 42, 42); > > Internal functions have the magical ability to accept both literals values and reference > variables, whereas userland functions have to choose one or the other. Uh, yeah I guess. But I would ask the question, why would you want to do that? The reason we don't make the ampersand a requirement is a legacy concern. But if you are writing a new function there is no legacy concern. So it would seem a developer would *want* to force the ampersand. Or is your point just that there are a list of possible options and you want the ability to use _all_ options from that list regardless of whether a specific option has a valid use-case? >>> 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. >> I am unclear how the optional ampersand at the call site will change the behavior. > > > I was referring to this line in the RFC: > >> If the argument is a prefer-ref argument of an internal function, then adding the |&| >> annotation will pass it by reference, while not adding it will pass it by value. Outside this mode, >> the passing behavior would instead be determined by the VM kind of the argument operand. > > > That means that for any function implemented internally as "prefer-ref", the user can > now *choose* whether their variable will be overwritten by the function. I don't know exactly > which functions this would affect, because as far as I know, the manual doesn't have a standard > way to annotate "prefer-ref". Which is kind of my point: it's magic behaviour which > sits outside most people's understanding of the language. Sounds like the solution then is to update the documentation? > I don't particularly see a problem with requiring a third change in the future. Hindsight > is a wonderful clarifier. And I believe elsewhere you have been debating me over the need for > incremental change. Caveat emptor. > > > The distinction I would make is between incremental change, and contradictory change. If we > later introduce out parameters in a way that's compatible with call-site &, that would > indeed be incremental change; the effort spent adding & would move code closer to the final > state. If we end up introducing call-site "out", the effort spent adding & will simply > be compounded with the effort spent adding "out". > Predicting the future is a mug's game, but it's at least worth exploring some > possible futures, and how decisions now might help or hinder them. I do agree that changes that are contradictory as problematic. However, in this case Nikita has weighed in and said "out" is unlikely to happen. So that seems to remove the concern about conflicts with out parameters? -Mike