previously #38298 (comment)
related #45624

Most of these functions appear to be confusing pointer equality with equality of the things pointed to.

This is pretty similar to https://github.com/carlmjohnson/pointer. Why not just use my third party package instead of having it in the standard library?

Why not just use my third party package instead of having it in the standard library?

I didn't know it existed until you posted it just now, nor would I have thought to go looking for a package like this. If I wanted a function like one of these, I'd just write it in whatever package I needed it in. I'd probably wind up writing it quite a few times across multiple projects.

I think some of the function names and godoc comments as proposed are confusing and/or misleading, but I think that I generally agree with the idea of the proposal. A lot of these are potentially useful in a lot of contexts and seem as good a fit for the standard library to me as the new cmp package is.

#45624 is a proposal to add this capability to the language directly.

@iand @Nasfame You are right, the name is also confused me, naming those functions is also one of the important topics, but functionality should be deterministic.

This is pretty similar to https://github.com/carlmjohnson/pointer. Why not just use my third party package instead of having it in the standard library?

@carlmjohnson

I didn't know about this library either until you pointed it out. Without it in std library, I prefer to implement it myself instead of searching on GitHub. It is commonly used but not complicated to implement. I also have an implementation at ptr, but how many people know about it until I bring it up?

I think some of the function names and godoc comments as proposed are confusing and/or misleading,

@DeedleFake

English is not my mother tongue, so there may be some expressions that are not clear in English. But these functional implementations are explicit.

#45624 is a proposal to add this capability to the language directly.

@ianlancetaylor

There is indeed some functional overlaps here, but cannot be completely replaced by #45624.

#45624 need language change, but this one don't need. Although it has been proposed for two years, there is still no key progress

This also provide other functions that #45624 not contains, such as handle default value, comparison and equality.

In addition, default value handle, in some cases, can replace the ternary operator. Consider the following situation:

func y(x *int) {
    v := 100
    if x != nil {
        v = *x
    }
}

// can simplify to 

func y(x *int) {
    v := ptr.ValueOr(x, 100)
}

• All the constraints are not restricted to pointers!

@Nasfame

In go, we can't, but I think this should be another issue to discuss type constraint. I had initiated discussion at golang-nuts, but not many people have paid attention to this question, and did not get the reply from the official team. https://groups.google.com/g/golang-nuts/c/uGU7sbKqVZ4/m/9qxpPN8jAQAJ

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

No change in consensus, so declined.
— rsc for the proposal review group