/cc @dvyukov

What if you store uncomparable types in a Value (maps, slices, funcs, ...)?

Mutex usually works well for protecting write side of Value.

@cespare that's a good point, I was thinking about pointers mostly, didn't think about storing values.

@dvyukov I was trying to avoid that, and it seemed logical to have CAS anyway since most languages that have atomic.Value-style built-in already supports CAS. (ex: c++ java)

@OneOfOne If the only argument is that other languages have it, then I propose to not implement it.

@dvyukov not at all, I was just giving an example.

A good usage case for it is a (doubly) linked list, and avoiding mutexes all together.

Lock-free doubly-linked lists are insanely difficult to implement and are very slow because (1) link-based data structures are slow due to indirection and (2) shared data structures with high mutation rate are slow due to cache contention. And they can be implemented with atomic.CompareAndSwapPointer.
This does not look like a very convincing use case for addition of the new API.

I understand that, but atomic.Value is there and it exists, it has Load/Store like the other types in the atomic package, it's missing a function.

It's not an addition of a new API, it's adding a missing functionality.

I think Dmitry is referring to the addition of this new function as "the new API".

I don't see how the new API would work with non-comparable values. It seems to invite misuse.

To risk repetition, if your use case is pointers then you should use atomic.CompareAndSwapPointer.

Value.Load/Store are different from CompareAndSwap/Add/Exchange:

1. They support a very well-defined use case (see examples), which is very efficient and relatively simple to code, and the one we want to promote for cases where high performance and scalability are required.
2. They are supported on all types as opposed to CompareAndSwap/Add.

No thanks, per conversation above.