What is the philosophy behind arrays not being copied when assigned to another variable?

Yes, that’s exactly the insight — the names themselves aren’t Julia objects or boxes or pointers or memory locations. I’m fully on board with @Henrique_Becker’s post linked above — I don’t even like the word “variable” because it has a lot of the “box” baggage in my experience. Assignments are just choosing a name for a Julia object to make your life easier.

You can name numbers, you can name arrays, you can name functions, you can name pretty much anything in Julia, and it’s all assignment. You can decide that you have a better use for that name and use the name for something new (as long as it wasn’t const). Or you might decide that it’s useful to have two different names that refer to exactly the same thing.

Somewhat confusingly, the poorly named “updating” operators don’t actually “update” (or mutate) a Julia object. Doing something like x += 1 is simply saying that you have a better use for the name x — and it’s going to be one more than whatever the value of x previously was.

Syntactically similar — but hugely different — is that you can use “indexed assignment” (y[1] = ...) or field mutation (y.foo = ...) to change some property about the thing you named y. Or you can broadcast into the object named y with y .= 1. Or you can pass it to a mutating function (like normalize!(y)). All of those things don’t really change anything about the name “y” itself, but rather they change the object that you chose to refer to by the name “y”. And there could be other places in your code where you refer to that same object by other names, it doesn’t matter, it’s all one object.

9 Likes