And the references are passed by value. There are two places you can find in RAM that will contain that reference, which once you penetrate through the abstractions and wrappers, will be a pointer; that second location is the reference that was passed by value. A reference is basically a pointer that the language prevents you from doing pointer arithmetic on, and in many languages such as PHP, is simply automatically dereferenced for you.
The reason why I brought up languages like Forth is that there really did used to be languages that did not actually "pass" things by value. Forth had a true pass-by-reference, in which there is no second copy of anything, neither the value, nor a pointer to the value. Now it's a dead distinction, in the sense that pass-by-value and pass-by-reference used to be distinguishing, because everything is copying something. Which is why the distinction is sort of confusing to try to apply to modern languages, and produces lots of heat but no light; it's dead, inapplicable to the modern language landscape.
The proper question to be asking is what permissions/privileges are passed by a function's parameter, whether you're allowed to modify it and have the modifications visible to the caller, whether you're not allowed to modify it at all (immutable languages, for instance), or whether there's an entire ownership system around what the passed-in value represents (Rust), not whether or not something was copied when the function call was made. Trying to answer this question in terms of "pass-by-X" doesn't help, if for no other reason than pass-by-X implies there's only two possibilities, and I outlined three classes of possibilities above, each of which can have their own further nuances. Is Rust pass-by-reference or pass-by-value? Well, the question is invalid, in either the original or the modern mutation of the meaning.
> There are two places you can find in RAM that will contain that reference
That is an implementation detail completely depends on the VM. There is one very simple exception to your example: call inlining. Pass-by-reference is a behavior specification, not an implementation specification.
> Rust
If Rust emitted purely pass-by-value machine code, zero-cost-abstractions would be impossible in the language.
Not according to the comment that I am replying to:
> A reference is basically a pointer that the language prevents you from doing pointer arithmetic on, and in many languages such as PHP, is simply automatically dereferenced for you.
Also, the implicit is usually pass-by-value.
function foo(a) { a++; }
function bar(ref a) { a++; }
b = 1;
foo(b); // Pass by value, implicit.
assert(b == 1);
bar(ref b); // Pass by reference.
assert(b == 2);
Heap vs. stack values are not the same thing as pass-by-reference and pass-by-value.
> Is Rust pass-by-reference or pass-by-value? Well, the question is invalid, in either the original or the modern mutation of the meaning.
What do you mean? Maybe you mean "invalid" as in "no one should ask this anymore," but in case you mean "invalid" as in "is an apple an orange?" then
- It's strictly pass-by-value in the classic meaning. Sure, because of immutability there's the obvious optimization the compiler can do which is, under the hood, pass a pointer to a caller's value, but you could also implement everything by copying without the programmer noticing a difference (except for how long the program takes to run).
- It's strictly not pass-by-reference in the classic meaning. The "references" are a type of value. Parameters never are equivalent to the passed-in variable.
Whether or not it's a useful distinction to make is another story. References-as-values seems to be the emerging dominant paradigm for language design, but I sort of wish there were more languages that let you say "this variable is the fifth element of this array."
> if for no other reason than pass-by-X implies there's only two possibilities
I guess because people have only ever heard of by value and by reference, but there are a whole bunch more: by name, by copy-restore, by sharing.
> Trying to answer this question in terms of "pass-by-X" doesn't help, if for no other reason than pass-by-X implies there's only two possibilities
No, it doesn't. Heck, when I learned pass- (or call-)-by-X there were three main values of X mentioned (and implicitly a near-universal number of possible alternatives): value, reference, and name.
There are actually several more recognized values; the Wikipedia article on Evaluation Strategy has a reasonably good list:
PHP has pass-by-reference: http://php.net/manual/en/language.references.pass.php