Talk:Value type and reference type

Does JavaScript not have value types?

According to JavaScript: The Definitive Guide (4th edition): "The types can be divided into two groups: primitive types and reference types. Numbers, boolean values, and the null and undefined types are primitive. Objects, arrays, and functions are reference types." … "Strings are an unusual case." — Preceding unsigned comment added by 2001:464F:23F3:0:D16E:6733:6BA1:273A (talk) 19:02, 8 December 2019 (UTC)

Article seems to conflate a few different things

This article seems to conflate a few different concepts:

1. Many languages support a special kind of value that points to an abstract memory location. Examples include "pointers" in C and C++ (where &i is a pointer to i — if i has type int, then &i has type int *) and "references" in Perl (where \$i is a reference to $i).
2. Many languages support a kind of variable that's an alias for an existing entity. Usually this is only supported for function parameters ("call by reference"), but in a few languages it's supported more generally; for example, in C++, int & i = j declares i as a "reference" to j, so any reads or writes involving i are implicitly forwarded to j. (Conceptually, we can imagine i as syntactic sugar for dereferencing a pointer i_ptr that points to j.)
3. In some languages, some kinds of entities are always implicitly accessed via a pointer/reference. An example is Java, where this is true of objects: Object obj1 = obj2 doesn't create a new object, but rather, it makes obj1 refer to the same object that obj2 currently refers to. This is different from C++ references in that either obj1 or obj2 can subsequently be changed to refer to a different object. Other languages with the same approach include C#, Python, and JavaScript.

These concepts all use the term "reference" in closely related ways (and sometimes the lines between them are a bit blurry); but I think that the terminology of "value types" vs. "reference types" specifically refers to concept #3. The idea is that, in languages like Java, there are some types of entities (non-object types) that can be accessed directly, and other types (object types) that can only be accessed via references/pointers.

So, I'd like to rework this article to specifically focus on concept #3. The article would still discuss #1 and #2, but only with an eye toward elucidating #3 and showing how it relates to concepts in other languages (or even in the same languages: C# has all three of these).

Would anyone object to my doing that? (Normally I'd just "be bold", but in this case it would mean removing a significant proportion of the current content of the article, so I figured it's worth discussing beforehand.)

—Ruakh_TALK
17:42, 29 August 2023 (UTC)

Addendum: I've now made those changes. —Ruakh_TALK 23:17, 1 September 2023 (UTC)

The article conflates more things than those! Specifically, and like much of the source material from which it is drawn, it conflates value semantics with an immediate (as opposed to pointer-mediated) implementation.

While it's true that the simplest way to implement value semantics for a type is to copy its contents on assignment, that's not the only way. Consider Java's BigInteger, to take one of many examples. The implementation is heap-allocated and therefore pointer-mediated -- it has to be, since the contents are of variable size, and possibly quite large -- but it still has value semantics: operations like "add" return new instances rather than mutating existing ones, and equality is by content, not by identity. Assignment is still implemented by copying the pointer to the object, but this pointer copy doesn't create an alias to a mutable heap structure, because the heap structure cannot be mutated, because the class has no mutating methods.

The STL collections in C++ also have value semantics, because their assignment operators copy the heap structure. This is true even though they're mutable! There are many other examples, in programming languages, of collection types with value semantics; the earliest clear example I am aware of is arrays in APL (1966), which are also copied on assignment. (One could argue that lists in Lisp (1958) are another example, but a little hand-waving is required, because Lisp lists are technically mutable; though in practice, they are usually not modified after being fully constructed.)

I know it seems odd to think of C++ collections as having value semantics. This is partly because they're mutable, partly because they're heap-allocated, and partly because we rarely assign them or pass them by value -- because we know that copy operation is expensive. Instead, we use explicit references. But the fact that a reference has reference semantics doesn't mean that its underlying type also has reference semantics. (For example, consider int&, the type of a reference to an integer.)

How can it be that a mutable type has value semantics? Because assignment makes a copy, the effect of any mutation is visible only to the variable through which the update occurred; so it's equivalent to assigning a new value to that variable. Consider, for instance, i++ where i is an integer; we could say this is assigning a new value to i, or that it's mutating the existing value. It actually doesn't matter which way we describe it -- because integers have value semantics, the two descriptions are equivalent. Well, the same is true for e.g. std::vector; we can describe v.push_back(x) as either a mutation of the vector, or as assignment of a new value to v. There's no way the rest of the program could detect a difference between those two operations.

So a type has reference semantics iff assigning it creates an alias to a structure and that structure is mutable. Otherwise, it has value semantics.

So now: what are value and reference types? To me, it seems straightforward: a value type is a type with value semantics, and a reference type is one with reference semantics. If you accept that, then there are many errors in this article; for example, in the table, it is not the case that all Java object types are reference types. It is certainly not the case that functions in C++ are reference types!

If anyone disagrees with me, I would love to hear your argument. If no one speaks up after a few weeks, I may revamp the article. ScottBurson (talk) 02:43, 29 January 2026 (UTC)

Check your talk page! I left you a comment! - Otherwise (Talk?) 04:18, 29 January 2026 (UTC)