Re: [RFC] Keep type of reference params

From: Date: Fri, 15 May 2020 11:49:34 +0000
Subject: Re: [RFC] Keep type of reference params
References: 1 2 3 4 5 6  Groups: php.internals 
Request: Send a blank email to internals+get-110165@lists.php.net to get a copy of this message
Hi, Internals, ---- En lun, 11 may 2020 11:34:22 +0200 Nikita Popov <nikita.ppv@gmail.com> escribió ---- > > I'm finding it hard to follow what is actually being proposed here at this > point (as many different ideas seems to be discussed at the same time). > I've granted you RFC karma on the wiki in case you want to write down > something. > > As other's have mentioned, this is not a simple topic from the > implementation side, so it's good to have a firm idea of how things would > work on a technical level. If you want to pursue the "inout" idea, I would > recommend reading through https://externals.io/message/101254 > in its > entirety, because there is quite a bit of inout related discussion in > there. My current assessment is that I do not see any way to implement > inout in a way that both does not use references and has acceptable > performance. (Implementing inout on top of references is possible, but has > impact on its behavior, e.g. the fact that the reference will be > initialized to null by default, even if the function throws.) > > One of the core problems is that any naive approach to inout (i.e. > literally implementing it as a read before the call and a write after the > call) will necessitate a copy of the modified value, precluding rc=1 cow > avoidance. Implementing array_push() as an inout operation would copy the > array every time a value is pushed. Maybe this is actually a fundamental > implementation-independent property of inout, if it has the semantics that > the original value is not changed on exception (a copy would be necessary > in case code later in the function throws.) > > Regards, > Nikita Nikita, I've already read your thread. I like your purpose about "Explicit call-site send-by-ref syntax". I don't understand why it wasn't accepted. Yes, you're right about performance then maybe this RFC doesn't make much sense. :( Thanks, anyway. You can remove my karma again. Regards -- Manuel Canga

« previous php.internals (#110165) next »