On Fri, May 8, 2020 at 8:49 AM Manuel Canga <p...@manuelcanga.dev> wrote:
> > > > > ---- En lun, 04 may 2020 19:33:51 +0200 Rowan Tommins < > rowan.coll...@gmail.com> escribió ---- > > On 04/05/2020 16:43, Manuel Canga wrote: > > > I think I’d be positive of adding `inout` keyword in order to: > > > > > > - Check type of out is equal to type of param( like example of my > first email ). > > > - Avoid modifying caller var value when the function throws an > exception > > > > > > Another huge advantage of adding inout parameters is that we could make > > it mandatory to mark at the call-site, and get the advantages of this > > RFC with less of the compatibility hassle of changing the way > references > > work: https://wiki.php.net/rfc/explicit_send_by_ref > > > > We'd still need to figure out how to smoothly transition built-in > > functions to use inout rather than by-ref parameters; but then we > > already have magic "prefer-ref" in internal functions, so maybe we > could > > come up with some kind of "prefer-inout". > > > > > Hi, Rowan. That's a good point. > > If nobody objects to this RFC, could someone give me(manuelcanga user ) > karma in order to create wiki page ?. > 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
