cc @dmitshur

note there's an entire section on Reference Types in the json article: https://blog.golang.org/json#TOC_6.

https://en.wikipedia.org/wiki/Value_type_and_reference_type

@ianlancetaylor: please explain what you want to say with your comment. I am having a hard time guessing.

@Tiffilore Sorry for being confusing. In the initial post on this issue you said "I have been trying to research what a reference type exactly is supposed to be." My comment was pointing you to the Wikipedia page that explains what a reference type is. It's a standard term in computer science.

@ianlancetaylor Thank you for answering. But I think you misunderstand my initial post on the issue. You are certainly quoting me wrong. My sentence does not end where you let it end.
I wrote that I have found no explanation from the resources of the Go project, however contradicting ones elsewhere.

I am not sure that you have read the Wikipedia article you are suggesting.
Well, I have and for several reasons, I do not really see that that could settle the matter.

That a term is a standard term does neither imply that it has a clear definition most people or the relevant group for the matter at hand agree upon nor that it is useful for certain purposes like for the purpose of classifying types in Go.

Let's look at slices for example: some consider them reference types, some don't and I think it really depends on the definition, who is right.

While I could not find a definition of "reference types" by the Go project (no, there is also no definition in the json article @dmitshur referred to), I found the commit I have referred to: "spec: Go has no 'reference types'" (b34f055). So there is no need to argue about what a reference type is or what a reference type is in Go or what types are reference types, since the matter has been already settled there. (I think it is worth looking at this commit in more detail).

Both blog articles, Go maps in action and JSON and Go have been written prior the commit I was referring to and thus, I think it is most likely that their use of the term "reference types" is outdated and should be changed therefore.

@Tiffilore It's true that I truncated the sentence in my quote, but I don't understand why the truncation makes any difference to my reply. There are many standard computer science terms that are not also documented by the Go project. There is no reason for the Go project to document them.

Let's move forward and focus on what, if anything, should change. Personally I think the blog post you mention (https://blog.golang.org/maps) is clear. The sentence from the blog is "Map types are reference types, like pointers or slices, and so the value of m above is nil; it doesn't point to an initialized map.". This uses "reference types" with the standard computer science meaning, and expands on it by explaining that map types are similar to pointer types and slice types.

It's true that the term "reference types" was dropped from the language specs, but I don't see why that affects less format documentation like the blog post.

So I don't see a problem here. Can you give an example of a specific change that you think should be made? Thanks.

@ianlancetaylor: obviously, there are still some misunderstandings, so I will try to restate my argument again and subdivide this discussion into separate points.

(1) Consistency
No, the term "reference types" was not simply dropped from the language spec, it was dropped for a reason. That reason was given in the commit message, "spec: Go has no 'reference types'" to quote it again.

My main argument is asking for consistency. If the decision has been made that there are no reference types in Go, please be consistent and do not continue claiming that there are in the blog.

You seem to have a different view on that and less of a problem with inconsistencies.

(2) Reference types in Go
Instead you want to re-open the discussion again whether classifying certain types in Go as "reference types" is a good idea or not. Although this is certainly an interesting discussion, I am unsure whether this is the right place to do that. Maybe commenting on the commit I have been referring to would be more suitable.

I do not know why exactly it was decided that there are no reference types in Go, I could only speculate and am unsure whether I am really suited to do so and whether this is the right place to do so, so I will refrain from it.

However, I have already indicated that the issue is more contentious than it might seem at first sight, a claim which you have chosen to ignore. Let me nevertheless give you a very small example to back up my claim: In this post, Dave Cheney claims that "unlike map and chan types slices are value types".

(3) Specific changes
I think I was pretty clear from the beginning: I suggested to dispense using the term "reference type" in the go blog. Again, I am not sure that I am the right person to offer a specific solution, whereas I am pretty sure that I am not obligated to offer a specific solution in raising an issue, but I can certainly think about it.

Clearly my contributions to this discussion are not helping, so I will step aside. Thanks for your interest in Go.

"The Go contributors are committed to providing a friendly, safe and welcoming environment for all, regardless of gender identity and expression, sexual orientation, disabilities, neurodiversity, physical appearance, body size, ethnicity, nationality, race, age, religion, or similar personal characteristics. " (https://golang.org/conduct)

I really apologize if I've made you feel unwelcome. I'm doing my best, and I will try to do better in the future. There are many other people on the Go team who can carry this issue forward.

Personally, I think the blog posts are fine and the spec should be changed.

Right now, the spec's non-use of "reference type" or any equivalent term makes its descriptions of the semantics of the relevant types fairly unclear: #5083.

I know that some folks don't like referring to certain Go language features as "reference types". I have an impression that it's because of the ambiguity between (1) "reference types", the general concept as described on the wikipedia page, which includes any type of pointer; (2) "references", the specific C++ feature; and (3) "pass by reference", which is supported by some other languages but not by Go. However, we need some term to refer to the concept, and as the blog post and other documents show, that term will be "reference type" unless someone comes up with a different Go-specific word for us to use.

There are some dilemmas for Go to make a clear decision to whether or not use the reference type term.
Sometimes, the term is helpful to make some explanations,. But sometimes, it brings more confusions.
That is why the term was in the spec but removed later.

There are still many articles, either official ones or unofficial ones, which are using this term.

There are some possible definitions for this term.

1. Types each of whose values may contain an underlying indirect part.

This excludes pointer types as reference types.
However, personally, I think this is the simplest and clearest definition.

2. Reference types just mean pointer types.

This needs to explain map / slice / channel / function / string / interface contain pointers in implementation internal.

This definition is implementation depended, so it is not perfect in syntactical view.

3. Types each of whose values may contain an underlying indirect part and types which explicitly contain pointers.

In other words, types contain (either explicitly or implicitly) pointers are called referenced types.

The latter two definitions need to mentions that values of some reference types may also represent non-reference properties.

Since @ianlancetaylor has thanked me for my interest in Go, I would like to thank him for representing Go they way he did. I always wondered how this comes about and your conduct helped me to understand why, so I sincerely thank you.