Hacker News Reader

Comment by Animats | Hacker News Reader

> We also believe that the terms “call-by-value” and “call-by-reference” are so hopelessly muddled at this point (between students, instructors, blogs, the Web…) that finding better terminology overall would be helpful.

Maybe that shouldn't even be exposed to the programmer. The programmer-level questions are, is it copyable, is it mutable, and is it alias-free? Whether it's passed as a copy or a pointer is really an issue for the compiler. If you're passed a read-only copy of something guaranteed to not be aliased, you can't tell the difference from a reference. Some Modula compilers made that decision automatically, based on object size.

Rust compilers have the info to do this. I'm sometimes asking myself whether I should pass, say, an array of 3 32-bit floats in graphics code by reference or by value. The compiler knows better than the programmer what the hardware can copy fast, and that may differ with the platform.

View on HN

> Maybe that shouldn't even be exposed to the programmer. The programmer-level questions are, is it copyable, is it mutable, and is it alias-free? Whether it's passed as a copy or a pointer is really an issue for the compiler.

The problem here is the definition of "call by reference". In C++ that means being able to change the value outside of the function taking the reference.

    void setByReference(float& v) { v = 123; }

    float v;
    setByReference(v);
    cout << v;          // prints 123

That feature of being able to pass by reference doesn't exist in say, JavaScript. you can only pass by value in JavaScript. The types of values in JS are undefined, null, boolean, number, string, reference-to-function, reference-to-object. You can never pass anything by reference, only by value.

And that's where it gets confusing. If you have a variable who's value is a reference-to-object you pass the value. The value being "reference-to-object"

To re-iterate

    const n = 1;    fn(n);  // call by value, type of value = number
    const s = 'abc' fn(s);  // call by value, type of value = string
    const o = {}    fn(o);  // call by value, type of value = reference-to-object

In C++ though, you pass the a reference to the variable itself (in the example above). That's called call-by-reference.

I can see why the OP feels it's muddled.

Yeah, this is one of those things that while it may be more technically correct causes a lot of unnecessary confusion. I remember being confused by this as a C++ programmer learning Java when resources claimed that Java was always pass by value where the actual behaviour in almost all cases (due to Java going almost all-in on objects) is what a C++ programmer would expect from pass by reference.

I still see even relatively experienced programmers who don't understand this, particularly working with Unity where a lot of programmers came from C++ to C# and don't realise for example that a C# function that takes a List 'by value' and modifies it is actually modifying the same instance that was passed in by the caller.

No, Java really is pass by value. You can rely on this in Java:

  String s = "hello";
  foo(s);
  assert s == "hello";

In C++, if the function takes a non-const reference, you can't.

Yes, Java always passes pointers to objects. But you can pass pointers by value. And passing a pointer by value is not the same as passing by reference!

I think the origin of the confusion around a function taking a list by value and the like is the implicitness of pointers in Java and its cousins. This Java method:

  void foo(List<String> strings)

Is the equivalent of this C++ method:

  void foo(shared_ptr<List<string>> strings)

True systems languages make the pointers explicit.

That's only because strings are immutable in Java. It's not true for reference types in general.

In C++ passing a pointer by value is effectively the same as passing a reference, the only real difference being that the syntax for accessing the underlying value is more implicit for a reference.

No, in Java, this is true for reference types in general. The method receiving the pointer can mutate the object, but it can't change which object the original variable points to.

This is also true when passing a pointer variable by value in C or C++. It is not true when passing a reference in C++ - the receiving method can change which object the original variable points to.

Ok, that's not really what your example showed though. You seem to be relying on string interning to have two different "hello" literals refer to the same underlying object and therefore be equal? Coming from other languages, and specifically C++, I tend to see `==` as value rather than reference equality so that wasn't immediately obvious to me.

The equivalent code in C++ has different semantics but a function that takes a non const reference in C++ cannot change what the reference refers to (references are immutable in that sense in C++, they can only ever refer to one object). What a non const reference allows in C++ is for the called function to change the value of the object referred to and since strings are not immutable in C++ that means that the value of string s could change, not the object identity.

With pointers to pointers, or references to pointers in C++ you can further change the object pointed to / referred to but not with references (there's no such thing as a reference to a reference in C++).

> The compiler knows better than the programmer what the hardware can copy fast

This is true, but aliasing makes it extremely difficult to automatically decide between reference and copy. For example, suppose you have a function that takes your array, and also a mutable slice:

  fn f(a: [float32; 3], out: &mut [float32])

And now you call it with the same argument twice:

    let a = [1., 2., 3.];
    f(a, &mut a)

The compiler cannot choose to pass a by reference here, since that would create simultaneous immutable and mutable references, which is forbidden by rust semantics

The problem is that the existing language concepts that implement these ideas are ambiguous in many languages. Does int *x imply that x is an optional value, or that it’s intended to be shared with/from others, or both of the above?

> The way we informally talk about programming concepts (like “pass a variable”), and the syntactic choices our languages make (like return x), are almost certainly also sources of confusion. The former can naturally lead students to believe variables are being aliased, and the latter can lead them to believe the variable, rather than its value, is being returned.

There's the problem right there: any informal talk about programming concepts is bound to lead to confusion because informal language is open to interpretation (no pun intended). That's why we have formal definitions for these terms, as well as language specs which define how pass-by-value and pass-by-reference (if applicable) and pass-by-address (if applicable) work in a given language.

Deep value equality can also be expensive to check, so some languages default to reference equality even for immutable values.

I used to think having both == and .equals in Java was specifically dumb, but the more I think about it, the more I dislike this kind of sneaky reference equality in the general case.

Comparing references isn't even an optimised version of comparing values, because when the references don't match but the values do, equality will be false.

I struggle to think of when reference equality would be useful to me. Like if I were writing a standard for-loop over an array, it's like I'd be comparing 'i' to 'i'.

If == gives me a fast 'yes' response, I feel like I (or my algorithm) should have already known they were going to be the same.

If == gives me a fast 'no' response, then do I not actually care about the value?

I think Python got this right, where "x is y" is identity (not often used but still concise) and "x == y" is value equality (a method you can override).

Reply on news.ycombinator.com