Hi! > This discussion seems to have lost track of the context ... the original > quote (which Stas cherry-picked in a way that lost the original meaning): > >> I think nowadays it is well known that by-reference passing is to be > avoided and I don't see it particularly commonly in user code. By-reference > passing is mainly used when it is needed to interact with existing > by-reference functions such as preg_match(). We can hardly switch these > functions to use out/inout if we require the corresponding keyword on the > call-site. > > You seem to be agreeing with what I originally said: That by-reference > passing is mainly useful to interoperate with by-reference internal > functions, which don't exactly leave you with a choice.
I do not think this is accurate, at least in my experience it completely isn't. Also, internal function accept by-ref for a reason - e.g., they need to modify arrays. The same reason would apply to any user space functions that also need to modify arrays, and since we can't have internal functions for every array modification that may be needed today and in all the possible the future, by-ref would be as needed for userspace as it is needed for internal functions. > that currently, both humans, static analyzers and the engine have a hard > time telling whether an argument is going to be passed by reference (or > otherwise indirectly modified) or not. Humans may use API familiarity to > help them, static analyzers can (unreliably) try to infer this through Why? This can happen only if you don't know the definition of the function being called. For human reader, it's rather unusual situation to be in - if you don't know that the function does, you stop and got read it's definition, otherwise you can't understand what's going on from now on - that happens regardless of whether references are involved or not. Once you've read the function definition (which you need to do anyway) you know whether references are involved or not. For the static analyzer, similar logic applies, except that it probably already knows the definitions of all functions (how it could analyze anything otherwise?). Only exception is when it's variable function call, which is quite rare, and mixing by-ref and by-value functions in such calls is even rarer (pretty much never to be done), so we should not really optimize for this rare and un-recommended case. > global analysis, while the engine is entirely out of luck apart from the > simplest of cases. The engine is doing the call! If it doesn't know what function is being called, it's a fatal error. So here I can't even imagine a situation where the engine wouldn't know whether passing is by-ref or not. Do you mean something different by "the engine" than I do? > Does that make sense, Rowan? To put is more compactly, what I want is an > eventual state where given $fn($a) I have a guarantee that $a is not going > to be magically modified, without having to perform any global reasoning How can you have this guarantee? If $a is an object, it can be modified by anything. If $a is an array, it still be modified if any of the elements is by-ref. Do you mean the content of zval underlying $a is not modified (except maybe refcounts)? That may be guaranteed but what is the use of such a guarantee for the user? > Bob has brought up another interesting issue: This proposal currently does > not address the case of foo(...$a), where references into $a may be added > if foo() has by-reference parameters. The suggestion was to use foo(&...$a) > -- however in this case only to *allow* the use of references, not require > it (some args may be by-val while others may be by-ref). That is confusing, now & doesn't actually mean by-ref, it means sometimes by-ref, sometimes maybe by-ref, sometimes just kidding, no refs at all. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
