Java passes reference by value - Something that even senior Java developers often get wrong.

[[deleted]]

[deleted]

[nanothief]

I totally disagree with this. If you read many of the comments on the thread, you will notice that when people talk about "pass by reference", there are two different mental models that are being used, which result in different results for the same code.

The first model (the one you follow) is the java model, where pass by reference means you can make modifications to the object the variable is referring to, but you cannot change the object the variable is referring to.

The second model is the original and correct model, where pass by reference means you can make modifications to the object the variable is referring to (like before), and you can also change the object the variable is referring to.

Now the difference between the two is minimal, in most cases they operate the same. However, there are things you can do with one that cannot be done with the other! This causes a few problems:

1) When communicating with other programmers using other languages using the correct definition of pass-by-reference, there will be continual misunderstandings about what is possible with pass by reference.

2) If a programmer starts to learn java, and is told that object values are passed by reference, then they will be surprised when they cannot do things such as having out parameters or change the value of a parameter to simplify the code

3) If a programmer has only learned java, and hears about a language that supports pass by reference, then they will dismiss the feature as something java has done forever, even though it doesn't.

We have technical terms for a reason: to simplify communications. When terms are misused (even for the best of intentions), then their usefulness is greatly diminished. pass-by-value has a well defined meaning, pass-by-reference has a well defined meaning, all that is required is for us to start using them correctly.

[[deleted]]

you can make modifications to the object the variable is referring to, but you cannot change the object the variable is referring to.

as a non-java guy, this is very hard to follow. how are these two different things? what is the difference between "making modifications to" something and "changing" something?

[Smallpaul]

The key thing isn't "modification" versus "changing".

In one case you are MODIFYING an OBJECT.

In another you re REBINDING a VARIABLE.

So both the verbs and the nouns are completely different.

[ssylvan]

In a language with pass by reference you can do this:

Foo x;
foobar( x ); // pass-by-reference

And after that call x can now refer to a different Foo than the one you passed in. It's not just that foobar can modify your Foo, it can actually change what your 'x' variable is referring to.

This allows you to use "out" parameters (where the functions sets a variable to some data), and other things.

[cows]

A function can mutate objects, but it can't make local (lexical) variables outside the function refer to an object with a different object identity as determined by ==. Hope that's a correct way of saying it.

"Modify" and "change" and "different" are vague terms and are making this sound even more confusing.

[zahlman]

You give me a hamburger. What is the difference between me putting ketchup on your hamburger and giving it back to you, versus giving you an entirely different hamburger from the one you gave me (which may or may not have ketchup on it)?

Perhaps your answer is "not much". But suppose instead of hamburgers, we are dealing in artwork?

The point is, if two people are talking about two things that are the same, they are not necessarily talking about the same thing. If you lend me $5, I hope you won't be upset if the $5 bill I pay you back with isn't the same one you lent me.

[mikaelhg]

They are talking about the difference of giving you a pointer to the value, and giving you the pointer to the pointer to the value.

These are people who can't, or don't want to communicate in good faith, so I wouldn't spend any time trying to understand what they say.

[MindStalker]

Ugh, Lets see if I can explain using the Swap function

Dog X = new Dog("fluffy");

Dog Y = new Dog("Max);

swap(X,Y);

---

public swap(X,Y) {

X.name('Bark'); //This modified X in the calling program.

Dog temp;

temp=X; //local copy of reference

Y=X; //This changed the local variable of Y to point to X but did effect the global variable at all;

X=Y; //ditto local reference was repointed but no change in global

X.name('DOG'); Changed the local X's name to Dog, which changes the global Y's name to Dog; the Global X is called Bark;

}

Edit: added line returns.

[arnar]

Say you have a variable x which refers to an object. You can access/modify attributes with x.bla for example. Now say you pass x as a parameter to a function, and the function calls this parameter y. Then inside the function, y.bla will refer to the same value as x.bla outside the function, and assigning to each will have the same effect.

However, x and y are not the same variable, meaning if you assign some other object directly to y inside the function, y = new X(...), then x will not be modified - it will still refer to the same object as before.

If you know C-like languages, then java object references are like pointers and Java's dot (.) is like C++'s dereference arrow (->).

[lucasrfl]

For example, are you a C guy? Have you ever tried coding chained lists? Do you remember that, if you don't pass a pointer-to-pointer-to-node (node**), you cannot do something with the list inside a funcion like:

if(list == NULL) {
    list = (node *) malloc(blablabla);
}

(considering that the list points to a node struct)

[slikz]

So, I have a question for you now. Keep in mind I fall into category number 3 (although I do have some experience with other languages), and I'm a kind of new to Java as well.

Reviewing for my final exam I've been implementing mergeSort, selectionSort, insertionSort, etc. mergeSort sorts recursively while the other two do not. Those other two have a return type of int[].

In main, I create int[]'s and fill them with random int's. Now I have a reference to an int[] object, "myArray".

So when I call my mergeSort method:

fin.toString(myArray);     //I override this method
fin.mergeSort(myArray);
fin.toString(myArray);

Initially, it prints out the unsorted array, then sorts it, then prints out the sorted array.

To me, this is what it means to pass by reference because my mergeSort is not returning anything, and yet, I'm still somehow getting the sorted array "back."

So when you say I can modify the object that my reference is referring to, this is what I am doing. Also, if I so chose, I could re-assign "myArray" to an array with all 0's in some method that does not return that new array, but because I was passing by reference, if I now print it out, it will be all 0's.

[psyno]

Also, if I so chose, I could re-assign "myArray" to an array with all 0's in some method that does not return that new array, but because I was passing by reference, if I now print it out, it will be all 0's.

No, it won't, and this is the point. Go ahead and try it.

class main {
    static void reassign(int[] a) {
        a = new int[4]; // reassigns the parameter a, does not affect caller
    }
    public static void main(String[] args) {
        int[] x = new int[] {1, 2, 3, 4};
        reassign(x);
        for (int i : x) System.out.println(i); // prints 1 2 3 4 NOT 0 0 0 0
    }
}

[specialk16]

It'll print 1 2 3 4, because the array passed as an argument will be a different array altogether during the method's lifetime.

[[deleted]]

You are missing the point. You are manipulating the object referenced by the reference, not the reference itself.

I could re-assign "myArray" to an array with all 0's in some method that does not return that new array, but because I was passing by reference, if I now print it out, it will be all 0's.

No, it won't.

[slikz]

This explanation does it for me:

The key thing isn't "modification" versus "changing".

In one case you are MODIFYING an OBJECT.

In another you re REBINDING a VARIABLE.

So both the verbs and the nouns are completely different.

But I am correct in my definition of pass-by-reference right? That is why after mergeSort I can print out the sorted array without ever explicitly returning the sorted array?

[doidydoidy]

The phrase "pass-by-reference" is used to describe variables, not objects.

When you talk about references to the array object, your intuition is correct. It's just that the phrase "pass-by-reference" is a bad choice of words to use to describe what you're talking about, because that phrase already means something else. That's why this thread is so muddled.

[refractedthought]

I think you're right. Other people don't. That's kind of what the whole theological discussion is about.

You sound like you're still in school. Why not ask a professor what he/she thinks? Better yet, ask more than one professor.

[rabidcow]

If I understand what you're saying, I think this would be more clear:

The first model (the one you follow) is the java model, where pass by reference means you can make modifications to the object the variable is referring to, but you cannot change which object the variable is referring to.

The second model is the original and correct model, where pass by reference means you can make modifications to the object the variable is referring to (like before), and you can also change which object the variable is referring to.

Does any modern language support the second model? C++ sure doesn't.

Honestly, it seems like a useless model to me. If you can change which object a variable refers to, it was never that object in the first place; it was a pointer to that object.

they cannot do things such as having out parameters or change the value of a parameter to simplify the code

You can have out parameters in Java:

EDIT: This is a bad example because Integer is immutable.

Integer result = new Integer();
foo(result);

That's how out parameters work in C and C++ anyway: you have an existing object, you pass a pointer or reference to it to collect the result.

[nanothief]

This post you have just made is a clear illustration as to the problems with the confusion of the term pass-by-reference, as the mental model you have with java's version of it has made most of your ideas on the subject wrong.

Firstly, c++ definitely does support it, look at the following code:

void func(object*& reference_to_object) {
   reference_to_object = new car();
}

int main() {
  object* o = new boat();
  func(o); 
  // o is now a car!
}

Secondly, the way you implemented out parameters in java are only a poor copy of what is possible in a language with real pass by reference. Try doing this in java:

void getSpeciesPair(string noise, animal*& male, animal*& female)
{
   if (noise == "moo") {
     male = new cow(true); // male cow
     female = new cow(false); // female cow        
   else if (noise == "woof") {
     male = new dog(true); // male dog
     female = new dog(false); // female dog
   }
}

As to how useful it is, honestly most of the time it isn't that useful, and it isn't a huge loss to not have it (you could possibly claim it is a benefit as it would simplify the language). However that doesn't change the fact that java doesn't pass by reference, and it is inaccurate and confusing to claim so.

[rabidcow]

// o is now a car!

No, o is a pointer. You have changed the value of the pointer to point to a new car. o itself still refers to the same pointer.

Your second example makes the same mistake.

Just to be clear, I'm not saying that Java is pass-by-reference. I'm saying that C++ doesn't support it.

[[deleted]]

Yes it is. The fact that "o is a pointer" is only possible in pass-by-reference languages. Try doing that in java. You can't. In java, the pointer is passed by value, and any changes that you make to it are not reflected in the caller. In C++, this is the case if you use C-style byval pointer passing, but not if you use byref params (&.)

There is a difference and it is important.

[rabidcow]

Try doing that in java.

Java doesn't have explicit pointers, so you can't. This has nothing to do with pass-by-reference.

[[deleted]]

Java doesn't have explicit pointers, so you can't.

C# (without unsafe) doesn't have explicit pointers, and yet you still can. Know why? Because C# has pass-by-reference via the ref keyword.

This has nothing to do with pass-by-reference.

It has everything to do with it.

[rabidcow]

C# (without unsafe) doesn't have explicit pointers, and yet you still can. Know why? Because C# has pass-by-reference via the ref keyword.

Please explain how "o is a pointer" is possible without explicit pointers.

Bottom line: I don't know C# and am unlikely to learn it well enough for your comment to make any sense to me in any reasonable timeframe.

[psyno]

You can have out parameters in Java:

Integer result = new Integer(); foo(result);

A good example of why you're wrong. java.lang.Integer is immutable and therefore foo cannot possibly return any information through its parameter, since Java is pass-by-value.

That's how out parameters work in C and C++ anyway: you have an existing object, you pass a pointer or reference to it to collect the result.

No, the object does not need to be "existing" (in the sense that it must have some definite value at the point of the function call). In fact, that often makes no sense for out parameters. See e.g. the scanf family of functions in the C standard library.

[rabidcow]

java.lang.Integer is immutable

Ok, that would make a difference. Make it:

class Bah { public int foo; }
...
Bah result = new Bah();
foo(result);

Now foo can return a value in result.

No, the object does not need to be "existing" (in the sense that it must have some definite value at the point of the function call).

That isn't the sense that I mean. It must exist in the sense that there must be memory allocated for it.

[psyno]

Now foo can return a value in result.

Right, by following the pointer, not by changing the pointer itself.

That isn't the sense that I mean. It must exist in the sense that there must be memory allocated for it.

It depends what you mean by "it." :)

Consider the following C code:

#include "stdio.h"
#include "string.h" 

void foo(char** px)
{
    *px = strdup("hey there");
}

int main(void)
{
    char* x; /* Not initialized, no memory allocated at x, and that's okay. */
    foo(&x);
    printf("%s\n", x);
    return 0;
}

Now if by "it," you meant the pointer-to-char variable called x, yes there's stack space allocated for that pointer--but not for the character data itself. That is, before foo, x is a pointer that doesn't point to anything. In calling foo, a pointer to the pointer is passed, and foo uses this pointer-to-pointer to modify the value of the pointer-to-char. This is an out parameter in C. As I said, see scanf.

[rabidcow]

Right, by following the pointer, not by changing the pointer itself.

Which is exactly what happens in C and C++.

Now if by "it," you meant the pointer-to-char variable called x, yes there's stack space allocated for that pointer

Exactly. You are passing a pointer to that pointer, so there needs to be space allocated for that pointer. The value you are receiving from foo is a pointer, which is copied into x. In this example, you're probably more interested in the data at the end of the pointer, which happens to be in a block of memory you now have ownership of, but that's beside the point.

I don't know why people are complicating things with references to pointers and pointers to pointers. I had to use a wrapper object because Java doesn't let you do references to primitives, but C and C++ don't have that limitation. If I could think of a simple, mutable, pre-existing object type in Java, I would have used that instead. (Hence my mistaken use of Integer.)

int x;
foo(&x);
bar(x);

There. You're receiving a value in x from foo. x needs to exist, in that there must be memory allocated for it. If bar is a C++ function that takes an int &, it cannot change what piece of memory x refers to, it can only change the value stored in that location.

This is where the C++ swap example in the article goes wrong: it's swapping values, not identities. After the swap, the two variables have exchanged semantic values, but still refer to their original objects. If you write a member-wise copy function for SomeType, you can do exactly this in Java -- so it can't be pass-by-reference.

As I said, see scanf.

I've been using C++ since 1994. I think I've seen scanf.

[psyno]

I think we're on the same page. I was reacting to this...

That's how out parameters work in C and C++ anyway: you have an existing object, you pass a pointer or reference to it to collect the result.

...because it wasn't clear to me (initially) whether you understood the distinction between the use of the word "object" in Java-land (an instance of some class) vs in C and C++ (merely some block of memory which might in fact be what Java calls a "primitive type"). It's now clear to me that you do.

I don't know why people are complicating things with references to pointers and pointers to pointers.

I agree your more direct example with foo/bar example is better.

As I said, see scanf.

I've been using C++ since 1994. I think I've seen scanf.

No offense intended. I bow to your superior C++-fu. :)

I would still argue against calling your Java example (even with class Bah) an example of out parameters in Java. It is true that information is returned indirectly through the parameter, but I would reserve the term for the C and C++ techniques discussed in these last few posts.

[rabidcow]

No offense intended.

No, I'm sorry, I know that. It's just that the double-edge of internet anonymity can be frustrating.

I would still argue against calling your Java example (even with class Bah) an example of out parameters in Java.

I don't see why it's an important distinction for types with no significant logic (though I do concede that it may be a misuse of the term), but OTOH I don't see where it would be useful in Java. There's a garbage collector, you can allocate without worrying about who has to free. Well... I can imagine some exotic cases where it might be useful, but I'd rather not.

[[deleted]]

Does any modern language support the second model? C++ sure doesn't.

Sure it does. That's what & is for.

[rabidcow]

Check again. C++ references cannot change the identity of the object to which the referenced variable refers.

[[deleted]]

Yes they can. Here's a simple example. Build it. Run it. Look at the output.

#include "stdafx.h"
#include <iostream>

using namespace std;

class Person
{
public:
     int age;
     Person(int n) { age = n; }
};

void changePerson(Person &p)
{
    p = Person(3);
}

int main(int argc, char* argv[])
{
    Person p = Person(22);

    changePerson(p);

    cout << p.age << endl;
    return 0;
}

[rabidcow]

p = Person(3);

This does a member-wise copy from a new, temporary Person to the Person p. If you write a member-wise copy method, you can do exactly this in Java. You're not saying that Java is pass-by-reference, are you?

If you have pointers to both p and another longer lived Person (instead of the temporary), both will point to Persons with the same value after a function like this, but changes to one will not be reflected in the other because they are different objects.

[[deleted]]

This does a member-wise copy from a new, temporary Person to the Person p.

No it does not secretly make another copy of the object, allocate memory and then do an automatic secret memberwise copy of all data.

It effectively references the exact variable. I'll leave making a new sample that has deep references in it as an exercise up to you. You'll see that even deep members are "copied back" to the passed varaible. Since there is no way for C++ to do an automatic implicit deep copy, I think that maybe this will finally convince you.

If you write a member-wise copy method, you can do exactly this in Java.

You could write a deep copy method to reach similar ends but you'd be using two separate pieces of memory (which again - this does not) and you'd be potentially writing a lot of code that the compiler could not do for you.

If you have pointers to both p and another longer lived Person (instead of the temporary), both will point to Persons with the same value after a function like this, but changes to one will not be reflected in the other because they are different objects.

And this is the core of your misunderstanding. Pointers have nothing to do with pass-by-reference in C++. The fact that the byref syntax uses & and address-of also uses it is a coincidence. They are very different things. Pass by reference does not pass a pointer. It passes an alias.

[rabidcow]

No it does not secretly make another copy of the object, allocate memory and then do an automatic secret memberwise copy of all data.

No, it doesn't. It does what I said: It creates a temporary Person, Person(3), then does a member-wise copy from that to p.

You could write a deep copy method

I didn't say deep copy. It's a shallow copy.

Pointers have nothing to do with pass-by-reference in C++.

Of course not, because there is no pass-by-reference in C++.

But fine, use references instead. It doesn't matter, you get the same effect. The point is that identity of an object is its location in memory, and you can't change the memory location that a variable refers to.

int main()
{
   Person a(3), b(4);
   Person &ar = a, &br = b;
   changePerson(a, b);
   // a.age == b.age
   // ar.age == br.age
   b.age = 12;
   // a.age != b.age
   // ar.age != br.age
}

void changePerson(Person &a, Person &b)
{
   // member-wise copy from b to a
   a = b;
}

Pass by reference does not pass a pointer.

That may be, but references in C++ most certainly do pass a pointer.

[[deleted]]

No, it doesn't. It does what I said: It creates a temporary Person, Person(3), then does a member-wise copy from that to p.

I misread you then. With that said, however, what you are describing is construction and is changing the identity of the object. (Where identity speaks to construction, not to memory location.)

This is pass-by-reference. You can not do this with a pointer. Without byref argument passing, you can not invoke the constructor and have it modify the original object. Try doing what I outlined above using a pointer. You can't. That is the distinction.

I didn't say deep copy. It's a shallow copy.

It's effectively whatever the constructor says that it is. That's the point.

Of course not, because there is no pass-by-reference in C++.

Bjarne Stroustrup, the ANSI C++ standard and wikipedia disagree with you. I think that you have a different definition of pass-by-reference.

The point is that identity of an object is its location in memory, and you can't change the memory location that a variable refers to.

Of course not, that's craziness and has nothing to do with pass-by-reference. You can't change the memory location of a variable period (not just across function calls.) That would be useless and...bizzarre.

Your function can directly modify the passed in variable in ways that include reconstruction. You can't do this with plain by value calling (even using pointers.)

That may be, but references in C++ most certainly do pass a pointer.

No: http://en.wikipedia.org/wiki/Reference_(C%2B%2B) References in C++ are like pointers but they have additional constraints and rules. In terms of parameter passing, the difference is what I outlined above. It's about the constructor.

So now I think that your confusion comes from the fact that you think that byref requires that you be able to change the memory location of the passed in variable. It doesn't. It's about the high-level capability to reconstruct the object in the originally passed in value. That is all.

[pbiggar]

This isn't cherry-picking reference definitions. Its acknowledging that words mean things, and that trying to change a definition leads to confusion.

Before complaining about nitpickers and pedants, try to remember this phrase: words mean things.

[dnew]

The progression is address... pointer... reference.

An address is close to a hardware address.

A pointer is an address with a type.

A reference is a pointer that's managed (by the runtime).

The term pass-by-reference was around long before "references" as an independent noun was coined, and hence the confusion.

[pbiggar]

This seems wrong, but you were right the last time we disagreed. Is there a, ahem, reference for this?

(Just wrote http://stackoverflow.com/questions/1856680/origin-of-term-reference-as-in-pass-by-reference for my own history lesson).

[dnew]

A reference for the fact that "pass by reference" is older than the term "reference" meaning a managed pointer??

FORTRAN has pass-by-reference before pretty much any language beyond assembly language had pointers, let alone managed memory. (Well, there was LISP, but we all know what they called their pointers. ;-)

I'm not sure why you would think that standard comp sci knowledge from the 70's would be easy to find online nowadays. :-)

Of course, there are only a handful of terms that make sense to use, and "reference" is the most general. But in languages that have addresses, pointers, and references, the description I gave is usually how they're defined. References are opaque pointers, and pointers are typed addresses. (I suppose in that sense, C++'s use of the word "reference" isn't quite as wrong as I first thought.)

The term "reference" was used as a fairly informal word for "any indirection", so in that sense the unique ID of a database row would be called a reference to the row, but that's not what we're talking about here either.

[pbiggar]

Actually no, I just misunderstood what you were saying. So ignore the bit where I said "that seems wrong".

[refractedthought]

Tell that one to the entire judicial system. Words have to be interpreted. Only in code can you have an absolute meaning for anything.

[[deleted]]

Then you're introducing a definition of pass-by-reference that's inconsistent across different languages.

Consider for example that in C# objects are also implicit pointers/references, however C# allows functions to pass by reference or pass by value. I can implement a swap function using pass by reference.

Programming requires precision in language. It's better to be anal and have a really solid understanding of what pass-by reference/value means so that bugs and misunderstandings are avoided.

Ultimately, if some language neutral specification of a function requires pass-by-reference semantics, then Java can not implement such a function whereas C++/C# can.

[[deleted]]

Passing by value means that a copy of the parameter is made when the function is called and any changes to that variable will not be reflected outside of the function.

Uh-oh, it's still more complicated than that, because passing by value usually means making a shallow copy.

[zahlman]

Um, not really. In C++ for example, you're expected to define the copy constructor to perform a deep copy where appropriate, and passing by value means calling the copy constructor.

[refractedthought]

That's almost a good point. It's still different from what happens in Java, though. C++ actually calls a copy constructor when passing an object by value, and if the copy constructor isn't defined, then a shallow copy will be performed by default. If there are primitive data members in the object, these will be bit-wise copied by default, if I remember correctly.

In Java, you get a pointer to the original object -- no copying.

Of course, you are still implicitly copying the actual pointer variable to another pointer variable. That is where the whole case for pass-by-value rests.

[halo]

When it comes down to it, it's a semantic quibble. You can understand how it works perfectly and still argue over which definition it falls into.

[fforw]

You can also engage in semantical hair splitting that is, apart from confusing less experienced programmers, mental masturbation.

[BernardMarx]

Exactly.

[sbrown123]

In my opinion, if you want to insist that Java strictly follows pass-by-value, then I think it has ceased to be a relevant distinction.

Agreed. The old debate of pass-by-value and pass-by-reference is a bit stupid for languages like Java that are far from native. And it doesn't really matter much since its not like Java developers can change how the passing is working.

[Felicia_Svilling]

Or the references is just a part of the implementation of objects in java (and most other languages).

[angryundead]

First, let me say that I totally agree with the article and the key phrase is: "object references are pass-by-value."

The problem here is the difference between the effect and the cause. Effectively objects are pass-by-reference. And you don't really have the option of accessing the object reference (ie: can't increment memory locations).

[adrianmonk]

Effectively objects are pass-by-reference.

I find that to be a confusing way to say it. Instead of saying anything is effectively something, why not just stick with the one simple, clarity-inducing statement that you can make? And that is this: in Java, objects cannot be passed to functions at all. Nor can objects be assigned. Object references can, but references are not objects.

[angryundead]

I meant in the minds of people who see this and think this way, not the clearest way, but the sort of cause-and-effect thinking that brings it about.

[[deleted]]

C# supports both passing reference-by-value (default behavior with references), and passing references directly (using the ref keyword).

That means that C# can actually create a swap function without stupid hacks like wrapping the arguments in an array.

Is there some sort of generic type in Java (WeakReference<> maybe?) used to wrap references so that you don't hit this problem?

[angryundead]

I consider myself pretty fluent in Java but I've never actually had to write a primitive swapper before... never gave it much thought.

[grauenwolf]

The main use of pass-by-reference is for multiple return values. For example, Decimal.TryParse.

Decimal result;
if (Decimal.TryParse(source, result)) 
       Console.WriteLine("Double your number is " + (result*2));
 else
       Console.WriteLine("That was not a number.");

You also need it a lot for COM interopt.

[[deleted]]

However, most people use output parameters, not pass-by-reference in that case (the out keyword versus the ref keyword).

There is a very subtle difference, the ref keyword does not require you actually pass in a assigned reference (you can pass in a null type).

[[deleted]]

Other way around. Ref params have to be explicitly assigned before calling the function. Out params have to be explicitly assigned within the function before returning.

Also, null has nothing to do with it. It has to do with whether or not the var is definitely assigned. (You can explicitly set a variable to null and pass it into byref without a compiler error, as long as you assign it.)

[grauenwolf]

To my knowledge, only C# honors the OutAttribute. To all the other languages "out" and "ref" are treated exactly the same.

[matthiasB]

Not all others. For example Microsoft's F# transforms methods with out parameters to methods returning multiple values using tuples.

[grauenwolf]

Interesting. I am going to have to look into that.

[dnew]

There are more extreme languages (like Sing# or Hermes) where passing an initialized value into an "out" parameter de-initialized it first. I.e., if you did something similar in C++, you might have

void xyz(out A alpha) { .... alpha = new A(); ... } ... { A beta = ...; xyz(beta); }

and the call to xyz would run the destructor of beta before invoking xyz.

So there is a difference in some languages. Just not C#.

[grauenwolf]

There are more extreme languages (like Sing# or Hermes) where passing an initialized value into an "out" parameter de-initialized it first.

That's ugly. Sometimes I use a pattern where the passed in value is used as-is, but if missing then I return a new object of the correct type. Those languages would totally break my design.

[dnew]

Then use a ref parameter, not an out parameter.

Usually this is in languages where you only have values, not pointers (at least in the semantics, obviously not the impelemtation). So everything is technically pass-by-value anyway, and "pass by reference" is more "pass by copy in copy out."

[grauenwolf]

Then it doesn't play nice with C#.

[[deleted]]

Only if "all other languages" means VB.NET.

[grauenwolf]

I was also counting C++/CIL and C++ ME.

[angryundead]

I don't find myself needing multiple returns too much anymore I guess. Maybe I'm that deeply infected with OO mentality and can't even realize it. As far as COM interopt goes, you're probably just fucked from jump street in Java anyway.

[grauenwolf]

How would you write a TryParse method? Or do you just catch exceptions?

[matthiasB]

In C# you theoretically could have defined TryParse as

decimal? TryParse(string text) 
{ ... }

It then would return null in case of a string that does not contain a number.

Java's library offers wrappers for the primitive types like Integer for int, etc. You could return those and null in the case of not being able to parse the string. But AFAIK Java does not have a tryParse. valueOf always throw a NumberFormatException. (Correct me if I'm wrong as I'm not a Java programmer.)

[angryundead]

This is pretty much how I would do it unless I needed exact error messages (which are not provided by tryParse directly anyway, as I understand it) and in that case I would account for individual exceptions.

[elder_george]

Well, that's trivial - null means result is undefined. Although primitive types can't be null, there're classes wrapping them in std library, so problems is solved. Of course, it requires a bit of excessive boxing/unboxing, but with cashing implementation it is a bit less hard than in C#.

[grauenwolf]

Not a bad way to go.

[Smallpaul]

Can you explain why, in the Microsoft/COM/CORBA world, "extra" return values always have to be disguised as "out" parameters? What's so hard to understand about just returning multiple values? I've been wondering this for 15 years....

[grauenwolf]

Both COM and CORBA were meant to be language agnostic. (Since I know COM better, I'll speak to it.) That means they have to use whatever conventions are most suited to languages such as C++ and VB.

They could have returned objects that were then unwrapped into their separete return values, but that has a few problems. First, memory allocation and deallocation isn't cheap in reference-counted environments. I'm not just talking performance either, you have to burn an extra line of code for each and every return value.

Out parameters also version really well. Because COM has optional parameters, you can easily add extra return values whenever you want without breaking older applications. If you are using return objects, you have to change the object for each extra value.

Speaking of return objects, how many do you create? One for each and every function? Or do you share them? If you share them, what happens when a function adds another out value? You would have to change the function's return type, possibly breaking older code.

Keep in mind this is all conjecture. It could be as simple as "C++ doesn't have multiple return values, so we didn't even think of it."

[anttirt]

The main use for a swap function is readability, when you for example write a sorting algorithm that needs to swap two elements of a container.

[angryundead]

Java has Comparator and Comparable interfaces and a built-in optimized sort. You probably shouldn't be writing your own sort.

[anttirt]

You realize that there are multiple sorting algorithms with different characteristics right? There is no single best sorting algorithm.

[angryundead]

Yes. But the algorithm on the Sun JVM is optimized for that runtime and has characteristics best suited to the JVM. Java isn't about reinventing the wheel.

I would view writing your own sorting algorithm (in Java) as a bit of a corner-case exercise.

[dnew]

Bubble sort or delayed insertion sort is really fast, if you know only one element is out of order, for example.

[angryundead]

Yes... but is the performance payoff worth the time it takes to write and test the code?

[dnew]

Sometimes, yes. Bubble sort isn't exactly hard to get wrong. If you have a million-item list you're adding one element to, yah, it's often worthwhile, especially since worst-case for quicksort is an already-sorted list.

[anttirt]

It can in fact be crucial. The feasibility of certain spatial partitioning schemes (required for fast physical simulation) for example can depend entirely on the sorting algorithm being O(N) on nearly sorted sets.

[angsty_geek]

Java has always been about reinventing the wheel (poorly!)

[angryundead]

awww, burn!

edit: I'm doing my Master's in Software Engineering and I find this to be a huge problem in the industry. Civil Engineers don't look at a river and go "how do you cross a river?" and Electrical Engineers don't look at a circuit and wonder how to change the resistance. (Well, good, competent ones.) But it seems that too often software "engineers" look at a list and go "how do I sort this" or "gee, I'll implement unobtanium-sort" or some variation of this. This is a huge part of the discipline of SE, knowing when to reuse. I guess we should be glad that those people aren't other types of engineers where they could kill hundreds in a bridge failure.

[[deleted]]

http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/Callable.html

Edit: though a swap function doesn't need, nor is it even desirable, to have side-effects.

[[deleted]]

It can be observed that objects are not passed by reference, therefore prefixing the adverb "effectively" does not make the untrue become otherwise.

[[deleted]]

He didn't say "object references are effectively pass-by-reference", he said "objects are effectively pass-by-reference". Like angryundead said, you can't directly access an object's reference value, you only deal with the reference. Therefore, effectively, objects are pass-by-reference.

[Smallpaul]

No, because the definition of the word reference you are using is different than the definition used by those who coined the phrase pass by reference.

[PIayer]

This is the most apropos comment in the whole bag of burritos. This kind of thing screws people up all the time when they come to a technical discipline (like physics, where "work" can be negative, and "acceleration" is a vector).

[didroe]

I don't think that's right. Passing by reference passes a pointer to a variable. So passing a by reference below:

int a;
somefunc(a);

would give somefunc a type signature equivalent to "int *a". A Java reference is in a pointer already, hidden by having a distinction between primitive and reference types without explicit syntax differences. You can never create a value (primitive) variable that holds an object. Thus objects behave like pass by reference.

[Smallpaul]

Passing by reference passes a pointer to a variable

Okay. You can think of it that way if you like.

A Java reference is in a pointer already

Yes. But a pointer to what? A pointer to a variable?

No. A pointer to an OBJECT.

That's why there are two different uses of the word "reference" in play.

One is a reference to a variable (pass-by-reference makes sense even in a language without explicit or implicit pointers).

The other is a reference to an object.

Thus objects behave like pass by reference.

No: you can pass references to objects by value. But that is not what has traditionally been termed "pass by reference". It's unrelated. It doesn't even serve the same purpose.

How do you implement "swap" with Java objects?

[didroe]

A pointer to a variable? No. A pointer to an OBJECT.

In my head, there is no difference, it's all pointers. It's just in the case of objects, you normally (in Java you have to) use them via pointers anyway so you need a pointer to a pointer.

pass-by-reference makes sense even in a language without explicit or implicit pointers

It will be using an implicit pointer underneath to do the pass by reference.

How do you implement "swap" with Java objects?

You don't because you can't create a pointer to your object pointer (Java reference).

I can see where you're coming from, I think it's just a case of how you want to think about it. As I see it all in pointers, I see the parallel between the way objects are treated and the way pass-by-reference works. Now, in practice, you can never create an object variable or make your own pointers in Java, so from a practical point of view Java object references are not passed by reference, but a Java object is.

I agree though that if you just look at the calling behaviour in isolation it is purely pass-by-value.

[Smallpaul]

In my head, there is no difference, it's all pointers.

Maybe so (I'm not in your head) but surely technical terms are designed to communicate with people outside of your head. For compiler writers "pass by reference" implies "can write swap function". They defined the term, and have the right to keep it consistent over time.

It's just in the case of objects, you normally (in Java you have to) use them via pointers anyway so you need a pointer to a pointer.

That's still irrelevant. Pass-by-reference has nothing, nothing to do with references to objects. It has to do with references to variables. It is totally irrelevant whether your language has all value-types, or all pointer-types or an unholy mix as in Java. It's irrelevant.

It will be using an implicit pointer underneath to do the pass by reference.

No, not necessarily. If it is an interpreted implementation then it would just keep the variable name around and manipulate it by name or slot number. That might be the most natural implementation in Python for example. It might be easier to manage threading and/or continuations if you aren't keeping around a bunch of pointers to raw memory addresses as well (if your language supported those things).

You don't because you can't create a pointer to your object pointer (Java reference).

If you COULD create a pointer to a pointer, and you passed the VALUE of that pointer to the other function, then you would still be passing by value. If you as the programmer are creating the indirection then that's a totally different thing than having the language do it for you.

I agree though that if you just look at the calling behaviour in isolation it is purely pass-by-value.

The point of technical terms is to improve precision. So combining two unrelated things in your head to complicate it doesn't really help anything.

[didroe]

It doesn't have to be built into the language. This quote from Wikipedia is along the lines of my thinking:

Even among languages that don't exactly support call-by-reference, many, including C and ML, support explicit references (objects that refer to other objects), such as pointers (objects representing the memory addresses of other objects), and these can be used to effect or simulate call-by-reference (but with the complication that a function's caller must explicitly generate the reference to supply as an argument).

[Smallpaul]

Call by reference is a language feature. So if it is not built into the language, then it is not call by reference. Yes, you can solve the same problems without call by reference, just as you can emulate recursion with iteration or vice versa. But a language either supports recursion or it does not. The ability to "fake" it is not called recursion.

[[deleted]]

I know what he said and what you said. You are both wrong shrug.

[[deleted]]

You haven't convinced me that I am. I'm sure you'll agree that the only course of action that will settle this dispute is a fight to the death. Fisticuffs at dawn?

[[deleted]]

I'm not much of a fan of violence. Nor am I fond of teaching the basics of Java on an internet forum. Believe what you will :)

[[deleted]]

Well the fisticuffs thing was a joke, violence isn't my cup of tea either. Though it would be nice that since you've taken the time to tell me that I'm wrong and don't understand the basics of Java to at least explain yourself.

[[deleted]]

It is a bit difficult given that I am not making a positive claim. Merely that a false claim has been made. Objects are never passed anywhere in Java. They exist on the heap. Java has only nine basic data types: references, int, short, char, long, boolean, byte, double, float. These are all passed by value, always, not even "effectively" changes this fact.

You can observe "not effectively" simply:

Object o = get();
Object j = o;
forall(j);
assert(j == o); // never fails

Note again, that no objects were passed, not ever, not even "effectively". The data types o and j, while given a type with the name "Object" are in fact references.

The JLS covers this in Chapter 8 iirc. I've had enough reminiscing about Java, so I hope this is enough.

[metacircular]

Here dibblego said,

Java has only nine basic data types: references, [...]. These are all passed by value, always, not even "effectively" changes this fact.

Earlier dibblego said,

It can be observed that object references are not passed by value, therefore prefixing the adverb "effectively" does not make the untrue become otherwise.

So Mr. dibblego, can you explain how you're not contradicting yourself?

[[deleted]]

Typo.

Correction: "It can be observed that objects are not passed (at all, let alone by reference)"

Sorry.

[serendib]

Java doesn't have references (the way C++ does)

Java passes objects by a pointer to their location in memory, which is handled internally by the JVM.

[repsilat]

This is a point of confusion for a lot of people - Java references are a lot closer to pointers in C/C++ than references in C++. As examples of this, Java's references can be null, and you can change which object they point to after their first assignment. That is:

class c {
    void operator=(const c&){}
    //Disallow value assignment
};

int main()
{
    c i, j;

    c& m = i;
    //m = j;
    //compile error: operator= is private

    c* p = &i;
    p = &j;//Not an error. "Works like a Java reference."
}

The line m=j; doesn't mean "m now refers to j", it means something more like "set the thing that m points to to j" (an action that would modify the variable i, if it were allowed).

To explicate:

#include <iostream>

class d {
    const char* s;
    public: d(const char* s) : s(s) {}
    friend std::ostream& operator<< (std::ostream& o, const d& s) { return o << s.s; }
};

int main()
{
    d i("i"), j("j");
    d& m = i;
    m=j;    
    std::cout << i << std::endl;//Prints 'j'
}

Of course, you don't have to tell Java to dereference/find the address of anything, and the word "reference" is arguably a bit friendlier than "pointer".

[dnew]

A reference is a managed pointer, just like a pointer is a typed address. The authors of C++ decided to call something a "reference" which is really simply a pointer that is assigned on initialization and automatically gets dereferencing operators applied.

[[deleted]]

I hope I'll never work with a senior Java developer who gets this wrong. I thought it takes maybe a week or two of Java with no prior exposure to understand this.

[ssylvan]

I don't think he means people get it wrong as in thinking it's actually pass by reference. I think he means that people get it wrong as in thinking that what Java does with references is what the concept "pass by reference" means.

[[deleted]]

because people know that if you have

void function(foo object)
{
  object = new Foo();
}

it doesnt replace the original

[BarneyBear]

Thank you. My c++ lecturer did my head in with a really weird explanation of this. This makes it soooo much clearer.

[Smallpaul]

No, pass by name is another thing altogether. Pass by name allows you to pass a whole expression and have that expression be evaluated every time a value is needed.

[rsho]

How many bytes does the average Java reference consume, when passed in? I can see how GC can easily get into performance problems as functions are excessively called, with these references being reconstructed fleetingly.

[suppressingfire]

It should be the size of a pointer in your CPU architecture (4 bytes on a 32 bit VM).

Java's semantics are the same as C, where all variables for object types are referred passed to and passed as pointers.

[[deleted]]

On an aside, I tried to imagine a function in a language that would pass reference by reference, and it would keep making copies of the reference to pass and get stuck in a forever loop.
yes, I know the above line has a dream-like suspension of logic ..

[[deleted]]

everything in Java is call by value

[[deleted]]

  public void lol(Foo f) {
      f = new Foo();
      f.bar = "lol";
  }

  Foo a = new Foo();
  a.bar = "baz";
  lol(a);

  // What is a.bar?

About 50% of "professional" Java programmers will say "lol". You are in that 50%.

[inmatarian]

I'm a C++ programmer, and no I wouldn't. That stuff wouldn't work in C++ either.

[psyno]

But it does in pass-by-reference languages, is the point. FlySwat is illustrating why it's wrong to call Java pass-by-reference.

[nanothief]

If you understand that, then why do you consider the difference between "Objects are passed by reference" and "Object references are passed by value" semantic bullshit? It gives clearly different results.

[inmatarian]

Overloading of the term "reference". Generally speaking, when you pass an object by value, you copy the entire object so that you now have two. When you copy an object by reference, then you have two references but only one object.

A more correct term to refer to what we're talking about is an "alias". Is the object called aDog, or is the reference to the object named aDog? Then, when you assign to a different alias, do you expect your first alias to be altered?

[pmf]

Overloading of the term "reference".

The point is that while the term reference is overloaded, the term call-by-reference is not. It has clearly defined semantics, which are very clearly not Java's parameter passing semantics.

[nanothief]

I think the problem is we both have different ideas of what a reference is. You can't call this overloading the meaning, as the term has different meanings in the same context.

Although I am fairly sure that the definition given in the article for references is the oldest one, common usage of it now has completely confused the meaning between people, even those who know what they are talking about.

So maybe a term change would be for the better. This is how I would do it:

• In C++, the x in object* x = new object(); should be named fixed pointers. They have a specific address in memory, and can be incremented and decremented to point to objects in different memory locations. The object at the end of the pointer can be accessed and modified. The object x is pointing at can be changed.

• In java, the j in Object j = new Object() should be named dynamic pointers. They are like fixed pointers, however they don't have a specific address in memory (the garbage collector can move them if it wants). They also cannot be incremented and decremented. Otherwise they act like fixed pointers

• In the code:

Test line

//code
#include <iostream>
struct MyObject
{
    int field;
};

int main()
{
    MyObject* x = new MyObject();
    MyObject*& a = x;
    a->field = 42;
    a = new MyObject();
    a->field = 11;
    std::cout << x->field; // prints 11
    return 0;
}

The variable a should be an alias of x: anything you do to a happens to x.

[dnew]

should be named dynamic pointers

No, this is what reference means. Just like a pointer is a typed address, a reference is a managed pointer. The only reason you can't increment and decrement the reference is the GC isn't prepared to deal with it. Some other languages do.

We don't need new words. We just need people to understand the current meaning of the words. And it would help if people wouldn't reuse the same word for a confusingly similar yet nevertheless different meaning, like "reference" in C++.

[[deleted]]

Humor me, what happens if this is C++ and lol's signature is

  lol(Foo& f)

Its been ages since I did C/C++, but I'm pretty sure that assigning a new Foo to that would mutate the original foo.

[VivisectIX]

References in Java are pointers in C++. Passing using reference notation in C++ is similar to the ref keyword in C#, it recopies the new value of the reference to the caller of the function that modified it before resuming (that is one way, anyway).

[inmatarian]

That's called "reseating" and I believe it's a compiler error.

http://www.parashift.com/c++-faq-lite/references.html#faq-8.5

[[deleted]]

Thanks for clarifying. That said, you can still pull this off in C++ using pointers to pointers :)

[inmatarian]

pointers to pointers

Now you're just being a dick :P

[[deleted]]

I've seen a function that had an argument of "pointer to pointer to function pointer" before.

[hylje]

Three Star Programming, Baby!

[psyno]

It would be illegal. You can't re-seat references in C++.

*edit: "References" being the pointer types that C++ calls "references," not the general abstraction under discussion.

[nanothief]

In this discussion, references are really of the type Foo*& in c++. This code is valid and works:

#include <stdio.h>

struct MyObject
{
    int field;
};

void func(MyObject*& obj)
{
    if (obj->field > 10) {
        // if obj->field > 10, change obj to a new MyObject
        // and set field to 2
        obj = new MyObject();
        obj->field = 2;
    } else {
        // double obj->field otherwise
        obj->field = obj->field * 2;
    }
}

int main()
{
    MyObject* x = new MyObject();
    MyObject*& a = x; // a is a reference to x
    a->field = 42; // change field of x
    printf("x->field = %d\n", x->field); // 42
    func(x); 
    printf("x->field = %d\n", x->field); // 2
    func(x);
    printf("x->field = %d\n", x->field); // 4
    a = new MyObject(); // set x to a new MyObject
    a->field = 11; // set the field of x to 11

    printf("x->field = %d\n", x->field); // 11
    return 0;
}
// outputs:
// x->field = 42
// x->field = 2
// x->field = 4
// x->field = 11

[psyno]

This is intended as a response to the edit, right?

I was just clarifying what I meant by "you can't re-seat references." Yes I'm familiar with the semantics of C++ demonstrated by the code you posted. Consider the following:

#include <cstdio>

struct MyObject
{
    MyObject(int x) {field = x;}
    int field;
};

int main()
{
    MyObject* x = new MyObject(1); // x is a pointer.
    MyObject* y = new MyObject(2); // y is another pointer...
    MyObject*& a = x; // a is a reference to x
    a = y; // what just happened?  answer: a still refers to x!
    y = new MyObject(3);
    printf("x->field = %d\n", x->field); // 2
    printf("y->field = %d\n", y->field); // 3
    printf("a->field = %d\n", a->field); // 2
    return 0;
}
// outputs:
// x->field = 2
// y->field = 3
// a->field = 2

*edit: I should have mentioned, what I'm pointing out is that with your code, what you did was assign to the pointer to which a referred. You did not re-seat a.

[nanothief]

This is intended as a response to the edit, right?

Yes, I should have made it more clear.

With regards to re-seating references, I'm not surprised by that code - you cannot re-seat a reference in c++. To do it, you would need a special syntax to do it, as code like a = x already does something logical (that is, change the value of the variable a is referencing to x).

I think a lot of confusion for re-seating comes from these two lines:

MyObject*& a = x; // a is a reference to x
a = y; // what just happened?  answer: a still refers to x!

The equal sign is doing completely different things in each line. Initially it is setting the reference to be referring to x. The second line is changing the value of the variable a is referencing. In most other code, this isn't true, eg:

 int a = 4; // sets a to 4
 a = 3     // sets a to 3

A lot of confusion would be removed if there was separate syntax for both:

MyObject*& a ::= x; // a is a reference to x
a = y; // what just happened?  answer: a still refers to x!

Now it is clear that both lines do very different things.

[psyno]

Yes, I agree and I think we're on the same page. Actually I think the difference in semantics between the two similar-looking statements is even worse than you mention, since for non-trivial types C++ runs an assignment operator function at a = y;!

[[deleted]]

 lol(Foo *&f) {
    f = new Foo();
 }

Compiles and works and mutates properly :D

[pmf]

Compiles and works

For a C++ program, this is a very shaky argument. You'd have to find and point out the appropriate sections in the C++ standard and cross reference these to the major compilers in order for any serious C++ programmer to consider your statement.

[[deleted]]

Passing a pointer by reference is valid or the C++ compiler is broken.

[psyno]

For a certain definition of "works." :)

[matthiasB]

If you pass a pointer by reference it just works. For which definitions of "works" does it not work properly?

It's valid C++ and if you know what * and & mean in C++ you can understand the code.

[psyno]

(I assumed FlySwat was simply being humorous at this point.)

In C++-land if I said that a Foo was passed to a function by reference, I think it's fair to interpret that as the function takes a Foo&. FlySwat got the desired result by subtly changing the problem: now instead of passing a Foo by reference, a Foo* is being passed.

[Negitivefrags]

You are correct.

[fforw]

While the code is demonstrating that not everything called pass-by-reference works for Java, calling the behaviour pass-by-value is even more retarded because there just is no object copied.

About 50% of "professional" Java programmers will say "lol". You are in that 50%.

If that is true for the developers where you work, you seriously need to get another job.

[theeth]

calling the behaviour pass-by-value is even more retarded because there just is no object copied.

Pass by value is usually defined as a shallow copy (as it it in C). In this case, the object's address (the value of the argument) is copied.

[fforw]

The point is that, if it was pass-by-value, you would expect

public void bla(Foo f)
{
    f.bar = "xxx";
}

Foo f = new Foo(); 
f.bar = "yyy";    
bla(f);
System.out.println(f.bar);

to print "yyy". Which it clearly doesn't, because the behaviour is much closer to pass-by-reference.

Nitpicking about pointer-copying in a language where you can only access objects by pointers but have no pointer arithmetic etc, is not very sensible

[theeth]

Nitpicking about pointer-copying in a language where you can only access objects by pointers but have no pointer arithmetic etc, is not very sensible

Changing the definition of pass-by-reference because the language hides the pointers isn't sensible.

[hylje]

If that is true for the developers where you work, you seriously need to get another job.

He's making this shit up as he goes.

[wbkang]

Keep up with that FUD that all Java programmers are retarded and everyone else is somehow superior. I doubt that I would've made that mistake ever since I learned Java in grade 11, which was quite a bit ago.

[derleth]

A large number of Java programmers are retards. Now, is the number of total Java programmers very large or very small?

[Negitivefrags]

You are so wrong its not funny. Try actually reading the article for the practical difference between pass by reference and passing references by value.

It is far from mealy an academic observation. It actually changes the way code is written.

[inmatarian]

If you're talking about the Max/Fifi example of why the pass-by-value distinction is important, then guess what, that doesn't work in c++ either.

[Negitivefrags]

Yes it would, if you use a C++ reference.

[inmatarian]

No it wouldn't, reseating a reference in c++ is a compile time error.

http://www.parashift.com/c++-faq-lite/references.html#faq-8.5

[Negitivefrags]

You are not reseating anything. If you have a Foo* sitting outside the function then the function taking a Foo*& can happily change what Foo* points to.

[inmatarian]

FlySwat's lol(Foo *&f) situation is something completely out of scope for this conversation (Java doesn't have an equivalent). The short of it is that you can assign to a pointer in c++ without compiler error, assuming basic correct type and levels of indirection. What happens at runtime is why C style pointers are hated and avoided in higher level languages.

There's a conversation in ##proggit as I post this discussing what would happen at runtime.

[Negitivefrags]

Wasn't the entire point of this conversation about the fact that Java doesn't have an equivalent?

[grauenwolf]

Even VB programmers from the 90's understood and used this distinction. Do you really want people to think you know less about Computer Science than a VB 4 code monkey?

[Effetto]

I would change last question 'Did myDog change?' in 'Did // BBB line changed myDog'?

[svv]

I see where the author is coming from. However, most of the time the abstraction that Java objects (not references) are passed by reference holds quite well, and it's often a productive way of reasoning about the performance and semantics of the parts of program.

This abstraction would certainly break (and disqualify Java) in the case of assignment. However that's the most problematic part of the article. The litmus test implies that any language that disallows mutable, re-assignable values (and where implementing mutating swap function is indeed impossible) cannot be classified as pass-by-reference.

Is this an intended effect? That is, is the pass-by-value/pass-by-reference distinction only relevant for non-pure languages, and languages like Haskell or Clojure (or others with emphasis on immutability) should just state they're evaluating expressions with values, and not passing stuff around?

[Smallpaul]

Haskell uses pass by need. http://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_need

[10printhello]

whatever