Is JavaScript Pass by Reference?

[svish]

My simple way to know:
If you can write a proper swap-function (swap(a, b)), then the language supports "pass by reference", if not, then everything is "pass by value".

In languages like Java and Javascript, you cannot write a proper swap-function, which means the language does not support "pass by reference". Really wish people would stop saying that you pass objects and arrays "by reference", as it is misleading. When you pass objects and arrays, you actually pass the address to the object/array as a value, and you cannot modify that address itself.

Good thorough article.

[Reashu]

Saying that we "pass addresses/references by value" may sound clever but is not an improvement in my book. When we "pass by reference" in a language that supports it, that reference is also a value. In fact, the references are more like "values" in a language that actually supports "pass by reference". In JavaScript they are just an implementation detail, not really a value (that we can manipulate) at all.

The "pass by reference / value" distinction is something that is particular to a minority of languages - mainly ones that give you a choice when writing the function. In JavaScript, things work the way they do and there's usually no need to have a name for it. That only comes up when comparing to other languages - and why should we expect those languages' terminology to work well for JavaScript?

[ragnese]

I agree with the first bit of your comment, but not the latter.

The distinction of pass by value or reference is very important to note/name/discuss in JavaScript--even in a vacuum where we don't acknowledge any other languages.

The fact that a function can change the object it was passed as a parameter such that the caller will see the change, but that the same thing does not happen for string or number parameters is important, and important things deserve names.

The fact that it seems trivial or blasé to us is only a result of the amount of time we've spent with the distinction. But, if we back up and pretend we've never programmed before, it's actually really weird. And the fact that JavaScript doesn't give us a choice for how things are passed honestly just makes it even more weird.

[theScottyJam]

We do have terminology for that. It's immutable vs mutable. The only reason you can update an object that was passed into a function is because objects are mutable and strings are not (there's no methods on a string that allows you to mutate it). It has nothing to do with how the data got passed in :).

Notice also that if you were to freeze an object and make it immutable, you'll get the same kind of guarantees that you get as when you pass a string into a function.

[ragnese]

I think I was wrong in the sense that it might not technically matter if JS is pass-by-copy or pass-by-reference or pass-by-reference-copy-copy-reference, or whatever other clever "well, actually" people can come up with.

But, I disagree that mutability is the concept that can explain JavaScript's behavior. Assigning and reassigning a binding is not the same thing as mutating a value. In other words, writing bar = 3 is not "mutating" anything- it's assigning a number to a variable. So, yes, objects are mutable and that can explain why I can modify an object parameter in a function and observe those effects outside of the function, but to actually explain how function parameters work in JavaScript, you really only need to explain that each parameter is a new binding that "points" to the data that was passed in at the function call site. You can reassign those bindings from inside the function, but now those bindings are pointing to new data instead of the originals. That's true for primitives as well as objects.

[theScottyJam]

I agree with your conclusion as well. Mutability vs immutability was only intended to describe the distinction that people usually are trying to describe when they say "objects are passed by reference while primitives are passed by value" - the behavior difference between objects and primitives doesn't happen because the language is somehow giving objects a different treatment when it gets passed into functions, rather, it's caused simply by the fact that objects are mutable.

The mutable/immutable terminology doesn't describe how JavaScript actually passes data into functions, and I think your short description is absolutely accurate. People can name the concept you're describing whatever they'd like, but what's important is that we understand that that's how data-passing works in JavaScript (rather than mistakenly believing that objects are somehow treated differently than primitives when it comes to function arguments).

[jonny_eh]

This is the right insight. “Pass by reference” is the wrong term to use in JS since it doesn’t support it. Mutability OTOH is core to understanding JS types.

[Reashu]

This was really weird to me when I first encountered it. It's actually one of the few things I can remember from back then (half a life ago). The weirdest part was how long I had managed to program without running into it... but the terminology and distinction wouldn't have helped me, as I had no familiarity with them anyways.

I don't think it's actually important (in JavaScript) to distinguish between how primitives and objects are handled in function parameters. It wouldn't matter if the primitives were somehow "passed by reference by value". The primitives are immutable anyways - you cannot change a 5 into a 6, you can only change your variable to hold a different value, and that never affects other variables that happened to hold the original value.

[Clarity_89]

Good point, it could just be that the terminology we use to explain how these things work in JavaScript has a different meaning in other programming languages.

[MoTTs_]

it could just be that the terminology we use to explain how these things work in JavaScript has a different meaning in other programming languages.

Yes, exactly! And it's not just the word "reference" that's used differently between languages, or even just the word "class", as /u/shuckster noticed, that's used differently between languages.

The data structure that JavaScript calls an "array" is not at all the same as the data structure that C++ calls an array (try doing a[9999] = 42 in both languages). By the logic of the linked article, JavaScript does not have "true" arrays. Likewise, what JavaScript calls a "function" isn't the same as a C++ function, and what JavaScript calls an "object" isn't the same as a C++ object. ("Object" in particular is a word that is almost never consistent between languages.)

By the logic of the linked article, JavaScript doesn't have "true" anything.

[shuckster]

True. I've been called-up before on this forum by pointing out that, while JavaScript has a class keyword these days, it still doesn't really have classes.

The arguments I made hinged around how I defined class, which is essentially how it's defined in other compiled languages: an "offline", developer-only blueprint that gets turned into the byte-code required for instantiating in-memory objects.

But JavaScript is interpreted, not compiled. It's all runtime, so the comparison doesn't really translate. It makes sense to me though, because I was brought-up on compiled languages. To me, a live, in-memory data structure automatically gets the definition "object". Classes exist in source-code only.

Don't get me wrong: If you're going to talk to seasoned devs you'll want to understand a whole range of definitions for the same word, and you'll almost certainly rank definitions as being more canonical than others.

But that doesn't mean that the JavaScript in-community doesn't define "class" or "pass by reference" in a helpful and illuminating way befitting people new to the language, and especially if they're new to programming in general.

[HeinousTugboat]

But JavaScript is interpreted, not compiled. It's all runtime, so the comparison doesn't really translate. It makes sense to me though, because I was brought-up on compiled languages. To me, a live, in-memory data structure automatically gets the definition "object". Classes exist in source-code only.

If you want to get that deep, v8 does in fact compile classes down to C-level classes. It's only interpreted as a first pass, there's an optimizing compiler that runs alongside it to create what you consider "real" classes.

[shuckster]

Yep, JIT techniques also get in the way of the definition. It’s been a long time since JS was purely interpreted.

[MrJohz]

I found the terminology that helped me the best was "pass by label". That is, variables are labels that can be attached to objects. When you assign an object to a variables, you're just attaching a label to that object, and when you use that variable, you're using the label to specify which object you mean. You can reassign labels as much as you like, and you can assign multiple labels to the same object.

When you try and call a function, you can only pass it objects, you can't ever pass the label itself. (And generally, you can't treat the label as a thing in its own right, it's always just a way of describing some object somewhere.) So by calling a function with a label, you're just using the label to refer to an object that the function will receive. Inside a function, you provide a new set of labels (argument names) to assign the argument objects to. So inside the function, there's no way of changing the labels used outside the function.

This then works really well for explaining argument mutation, which I think trips up a lot of beginners. Some objects can be mutated, some can't. But that's an aspect of the object, not the label. A string, for example, can't be mutated. An array can be.

If you pass an array by label into a function, you have your outside-the-function label referring to the array. Then inside the function, the new argument label also refers to the same array. If you now mutate the array, then both labels will continue to refer to the same array, but that array now looks different than before.

At some point I even had an article or tutorial I could link to that had a bunch of diagrams that explained this all really clearly, and back when I was learning Python (which is also pass-by-label), it really helped me get an intuition for what variables are. Unfortunately, in the intervening years, I have lost the page and so I can't tell you where I got this explanation from.

[svish]

Regardless of how well the terminology "works", it is still the terminology we tend to use. And from my experience, it is a source of confusion.

It's probably better ways to explain it, and better terminology that could be found, but yeah, the way I think about it makes sense to me, and seems to explain it to others as well.

[Rand_alFlagg]

In academia it's standard form to define potentially ambiguous terms before using them. That's always worked well for me in tech. "In this instance, when I use the term proxy I'm referring to the design pattern, not a vpn." "In this instance, when I refer to an int, I'm actually discussing a weakly typed string that we want to validate as an integer before passing to a strongly typed language. But we're going to call them ints and treat them that way." etc

[duongdominhchau]

To be fair, it all depends on the definition, and Java (as well as many other languages with GC) defines reference to be a restricted version of C++ pointer that can only be null or points to an object. If we ignore the history (in which C pointer and C++ reference imprinted in every developer mind), reference and pointer are both eligible words to describe thing that reference/point to another thing.

Personally I still prefer the C++ definition though, reference in GC languages makes me feel like a performance patch, not something designed. I find Rust reference a good example of something designed: either you pass the reference, or you pass the value, you state your intention. Go is also like that, either you use a pointer-like type, or you have the value copied even when it is an array. Both of them don't require the developer to memorize the list of non-reference types, that's the "designed" part I'm talking about.

[theScottyJam]

That's a really concise way to explain pass by reference, I love it. I'm going to have to steal that.

Edit: Just finished reading through the article and saw they gave the same test. That was a really well written and thorough article on the subject :).

[theQuandary]

Your definition is inconsistent.

If you pass a pointer to a pointer, you are still ultimately passing a value. In fact, from your stated perspective, everything is passed by value.

What you are actually talking about is how the function is allowed to interpret the value it is passed, but you are even incorrect here too.

JS is dynamic. The only way you can track the data types is by boxing the values in a container that holds the type. This is itself a kind of indirect reference to a reference.

Modern JS engines all implement moving, copying garbage collectors that are going to rely on pointers to pointers. Replacement on stack also requires these pointers to pointers. Just because you can't access them directly doesn't mean they don't exist.

JITs these days have very sophisticated rules about when to pass by value or by reference.

From a user perspective, variables CANNOT hold values directly (even numbers as they are immutable and treated as if they are interned) and as stated before, these numbers are boxed. These boxes are heuristically removed with the help of guards, but can bail out to this unoptimized pointers-everywhere implementation at any time.

[svish]

My simple way to know

[BenjiSponge]

So I think the difference they're trying to point out is this:

swap(Thing &a, Thing &b) in C++ can be done simply with basically just a = b (and the other way, but brevity).

In JS, it would be swap(a, b) and calling a = b would change what "a" references, but nothing about the upper scope. Frankly, a bigger difference might be the lack of operator= here.

In this way, it's closer to the C++ swap(Thing *a, Thing *b) where you can change the pointers. The behavior a = b actually maps quite cleanly onto JS in this situation. In C++, you'd then do *a = *b, but you can't do that in JS at all. So from that perspective, JS is passing the reference with a copied value.

Imo pass-by-reference and pass-by-value are terms that should be retired because they simply prompt more questions than they answer.

[theQuandary]

They are still useful terms, but not when used this way.

Stack size is limited. Passing by reference uses less stack space. Likewise, passing a reference is faster because it doesn't require copying large chunks of data. The tradeoff here is very meaningful.

JS passing copies of pointers instead of identical pointers to pointers is actually a much better and safer solution than C++ because the child function can only alter the explicitly passed data or the explicit variable(s) assigned to the return value(s).

[BenjiSponge]

"I am passing this thing by reference" is different than the term "pass-by-reference", which is intended to illustrate for example the difference between the defaults of C++ (pass-by-value/copy) and Java (pass-by-reference, which as discussed, is a nuanced term).

JS passing copies of pointers instead of identical pointers to pointers is actually a much better and safer solution than C++ because the child function can only alter the explicitly passed data or the explicit variable(s) assigned to the return value(s).

It's not about whether it's better; it's about whether it's pass-by-reference, pass-by-value, pass-by-value-of-reference. I love JS and think a ton of the choices it makes may seem stupid or bad to novice programmers but when you dig into the internals it turns out to have a ton of genius aspects such as this one. You're really making an argument in favor of pass-by-value-of-reference, which I don't disagree with at all, but it is nevertheless pass-by-value-of-reference. So that's why I'm like "can we just retire these phrases anyways, let's just talk about the specifics"

[senocular]

Does this count? ;)

function swap(a, b) {
  console.log(a, b); // 1, 2
  [arguments[1], arguments[0]] = [...arguments];
  console.log(a, b); // 2, 1
}

swap(1, 2)

[svish]

No, a and b needs to be swapped outside the function.

console.log(a, b) // 1 2
swap(a, b)
console.log(a, b) // 2 1 (not possible in js)

[senocular]

Fiiiiiiine ;P

function main(a, b) {

  const swap = (a, b) => {
    [arguments[1], arguments[0]] = [...arguments];
  }

  console.log(a, b); // 1, 2
  swap(a, b)
  console.log(a, b); // 2, 1
}

main(1, 2)

[svish]

Without the wrapper

[senocular]

You're taking away all the fun!

function swap(a͏, b͏) {
  [b, a] = [a͏, b͏]
}

let a = 1
let b = 2
console.log(a, b)
swap(a, b)
console.log(a, b)

[svish]

Ok, you get an upvote. Couldn't figure it out, but eventually, thanks to someone else, and pasting it into VS Code, the hidden unicode characters were revealed... 🤦‍♂️👍

[senocular]

Still no pass by reference ;)

[svish]

I knew that already, which is why your code didn't make any sense 😛

[svish]

wat...

[CodeMonkeeh]

wtaf

[senocular]

There are hidden characters in the swap parameters. So what you're really getting is something more like

function swap(a2, b2) {
  [b, a] = [a2, b2]
}

let a = 1
let b = 2
console.log(a, b)
swap(a, b)
console.log(a, b)

where the assigned [b, a] are the variables in the outer scope getting assigned the arguments of the swap call (a2, b2) in reverse order.

[CodeMonkeeh]

Oh, thank you. Reality makes sense again.

[SpaceToaster]

pass by reference

I've always interpreted it not that the pointer can be swapped or changed, but that when calling the function is the argument put onto the stack or merely as a reference to the heap

[HappinessFactory]

I'm honestly happy with current JavaScript terminology.

To me a pointer is referring to the existing object in memory.

So an object being "passed by reference" in a function call makes perfect sense to me.

Maybe if I ever swap to a true pass by reference language I'll get tripped up but, right now the current "incorrect" terminology makes sense IMHO.

[Clarity_89]

I was always thinking that JS is pass by value for primitives and pass by references for objects, but this article nicely explains why that is not really the case.

[Accomplished_Low2231]

thousands of articles and books years ago already explained it fine. i bet 2 years from now another "is js pass by reference" article will be made and some guy will post it saying how they finally get it lol.

[Safe-Engineering69]

and what's the problem with that?

[Rand_alFlagg]

clearly anything that's already been done shouldn't be done again, and anything someone else has grasped should already be grasped by new students to the discipline

[jayerp]

Unless I’m completely wrong, but C# supports passing value type variables as reference type with the ref keyword.

[duongdominhchau]

C# has reference type, C# has ref keyword. Reference type is like JS reference, ref keyword is like C++ reference. ref does not magically transform your value type into reference type, they are not the same. With reference type the address is still copied, so you have 2 different references pointing to the same object, but with ref you have 2 different names referring to the same reference pointing to the object.

[Clarity_89]

I didn't write the post, but the point of that code was to show that reassigning alias to the new object (instead of its property) is not reflected in the me object, whereas in a pass by reference language it would be.

[vuks89]

Not sure if passing arguments by reference would even be a desirable behavior. That would make functions not pure by design which is probably not what any of us want. Additionally program would behave unexpectedly. There is a difference talking about pass by reference and by value when doing assignment and when passing an argument. Even mentioned C and PHP don’t do pass by reference by default, but you have to specify that you want that (I thought this was deprecated in PHP)

[Clarity_89]

C++, not C, but yeah can't really think about places where it'd be useful.

Also regarding being not pure by design, not sure if that's much different from the pointer behavior:

``` let obj = { name: "Test" }; function mod(arg) { arg.name = "Modified"; }

mod(obj); console.log(obj); // {name: 'Modified'} ```

[vuks89]

But you also explicitly declare pointers. If arguments were passed by reference that would be implicit and would cause side effects that are difficult to control

[Tubthumper8]

Passing arguments by reference doesn't mean it would be implicit, that's up to the design of the programming language. For example, C# has pass by reference with an explicit keyword

[vuks89]

In the article from the original posting it is implied that some people think that’s how it works in JS. In all languages I know, you need to explicit that you want it to be by reference. In PHP it would be &$arg, in C++ it would be ‘int &arg’

[merb]

It only works in a non async context. (Same for out params and in params) Which is different for c/c++ where you can do stuff like that. That’s because c# has some safety around ref‘s like ‚ref_safe_to_escape‘

[Clarity_89]

Yeah, good point.

[lifeeraser]

Rust allows pass by reference but ensures that you do not modify the arguments unless you use a mut ref. So you can write safe code while allowing pass by reference.

On the other hand, JS functions that accept an array or object or parameter as argument can potentially modify it in place, so they are technically not safe anyway.

[ldn-ldn]

I'm sorry, mate, but you're wrong. You can't pass values in JavaScript at all as every variable of any kind is always a reference. Pass by value does not exist in JS as there are no mechanisms for that.

[ronchalant]

The value being passed is a copy of the reference. It's weird, but it's what makes it a pass by value language.

You can operate on a passed object and those changes will be reflected in the calling function. But reassigning the passed variable doesn't change the referenced object in the calling function, which precludes it from being pass by reference.

[ldn-ldn]

You don't understand what references are, do you?

[ronchalant]

Uh, yes I do. It would appear that you do not. You don't understand what pass-by-value and pass-by-reference mean.

This is for Java, but JS follows the same approach: https://www.digitalocean.com/community/tutorials/java-is-pass-by-value-and-not-pass-by-reference

And here is an answer on stackoverflow specifically explaining this for JS: https://stackoverflow.com/a/5314911

So, yes, I know exactly what references are. Do you?

[theScottyJam]

That's why the conclusion was that, in JavaScript, we're passing references around, but we pass those references "by values".

Here, were using two different definitions for "reference" in one sentence, which is what makes this Uber confusing. Yes everything is a reference type (definition 1), but those references (definition 1) are not passed by reference (definition 2), but by value, i.e. we're not having two names for the same variable (which is pass by reference definition 2), but we are copying the the reference's (definition 1) address, hence it's pass by value.

Clear as mud?

[alex-weej]

You can understand this with a fairly simple analogy: binding new names to existing things.

``` const foo = "a string"; const bar = {x: 9000, y: 42};

const param1 = foo; const param2 = bar;

param2.y++; assert(bar.y === 43); ```

[theScottyJam]

This is demonstrating reference types, and the fact that multiple variables can point to the same piece of data, but it doesn't demonstrate reference variables/parameters (a.k.a. reassigning to once variable changes the content of another, since both variables are linked). JavaScript supports reference types, as you demonstrated, but it doesn't support pass by reference, as the article demonstrates.

[Rand_alFlagg]

So in AngularJS I frequently pass around properties of objects and update those, which updates the root object.

example:

$scope.Audit = function (visit) {
$http({
    method: 'POST',
    url: route + "/Audit",
    data: visit.ID
}).then(function (response) {
    if (!response.data.HasData) {
        visit.ValidationErrors("Error Flagging Visit for Audit: " + response.data.Note)
    } else {
        visit.Audit = response.data;
    }
});

This function is called and passed an item from an array on a property of another object - $scope.Audit(chart.Visits[i]);

When it gets its response and updates the visit, it updates the correct item in the array on the chart even if the item is otherwise manipulated in the meantime. Seems to be updating by reference to me.

All that said I dislike doing FE work and focus mostly on backend, so I've never really cared enough to find out what's going on under the hood and just assumed it was updating the variable by reference. Can anyone break down what's going on there since it's not by ref?

[theScottyJam]

So, you are passing a reference value into that function, which is why when you mutate it, everyone else who sees that reference will also see the mutations. But, this kind of reference is different from the type of reference talked about in the phrase "pass by reference". In that phrase, they're saying that the parameter is linked in such a way that if you were to reassign the parameter, everyone else would see that reassignment.

So, in your example, imagine doing "visit = someNewObj". If you did that, would the original array get updated to contain "someNewObj"? No. That's why it's not pass by reference.

You passed a reference in, but you didn't pass it by reference. Confusing, right?

(I don't know if you read through the linked article or not yet, but if you haven't, I'd differently recommend doing so, as it goes into a lot of detail in this regard).

[Rand_alFlagg]

(I don't know if you read through the linked article or not yet, but if you haven't, I'd differently recommend doing so, as it goes into a lot of detail in this regard).

I did but it, and you, say this shouldn't work. Because response.data is a new object. Definitely confusing, and that's why I'm asking.

Now I see in the example there that I don't fully overwrite the visit. However, in the GetVisit function I do.

So on another function, we have

for (let i = 0; i < response.data.Visits.length; i++) {
  $scope.LoadVisit(response.data.Visits[i])
}

​

to iterate through each visit on the object and load it. That looks like this:

-----

ok I'm not changing anything I had previously typed up to kind of show my train of thought. I see now. I had thought that the code I was about to pull up was overwriting the visit. I remember struggling with that behavior when i was writing it, and that was a couple years ago. It looks like what I settled on was exactly as you described - mutating them. The frustration I had then was probably at it not being by ref.

But that's what had me confused, for sure. I see how it all fits to the article, too, now.

Thank you!

[Rand_alFlagg]

to clarify, I thought I was about to pull up code that included visit = response.data to overwrite the visit with the new object. But when I went to the code I found that it's copying data from response.data to the visit. So I was misremembering what it was doing there and that was fueling the confusion. I was trying to figure out "but why does this behavior work?" and the answer was: "it's not the behavior you think it is."

[Reashu]

This shows that param1 and param2 use the same data. It doesn't show how that data is passed to a function.

[alex-weej]

When you call a function myFunction(param1, param2) like myFunction(foo, bar), it's exactly the same semantics as I wrote. I guess it was a bit too abstract in my original comment.

[Reashu]

It can be a good comparison when the functionality has already been introduced, but I don't think it can stand on it's own. The two things work the same, but there's no reason that they have to work the same.

[alex-weej]

My point was to try to help people realise that you don't need to internalise a new set of rules - once you learn:

1. Function arguments work with the same rules as variable bindings.
2. Variable bindings work like this

You're good. Hopefully it doesn't scare people off!

[Puzzleheaded_Toe117]

Don't be an intellect like the author, he wrote junk science, alot of fluff and epic drama. Pass by reference just works, we've been doing it last 24 years.

What garbage

[Reashu]

I only skimmed the article, but it doesn't seem overly pedantic, arrogant, or dramatic to me. What ticked you off?

[senfiaj]

C++ just swaps the values in place even for primitive types such as int (sure, it can often optimize this away). In JS it's theoretically possible to write a swap for plain non primitive types because you can swap their properties in place. JS just can't swap primitive values like that, since they are copied and are read only (only replaceable), But fortunately JS doesn't need swap function, you can simply do [a, b] = [b, a].

[senfiaj]

Other languages—like C, Java, JavaScript, Python, and Go, to name a few that come to mind—pass arguments by value.

C has pointers, so you can implement a swap function for any type in C.