This seems like a subset of operator overloading; see #27605. It would probably be best if you added to that discussion instead of opening another proposal.

The copying method is essentially the same that was proposed in #21604.

Note that the current implementation relies on stack copying. If a type with a Clone method is stored on the stack, the method would have to be called while copying the stack, which is unlikely to work. But I guess that it would be possible to declare that types with Clone methods may never be stored on the stack.

Note that the language currently does not treat any user defined methods as special. This proposed change would be the first case in which that is done. Even the Error method is only special in that it permits satisfying the language-defined error interface. (One minor exception, not really in the language proper, is that when crashing due to an unrecovered call to panic, the runtime will call the Error or String methods, if available, when printing the value.)

I agree with the above that this is similar to #21604 (which was closed) and #27605.

Thank you for bringing up other proposals #21604 and #27605 which I wasn't aware of. In fact, one of them is my old proposal.

I am not sure whether my current proposal should be closed and I should join the discussion in those other proposals. While there are some overlapping areas, those proposals aren't the same as this proposal.

#27605

#27605 proposes operator overloading, but does not mention cloning/copying at all. The listed must overload operators are mathematical operators, such as +, -, *, /, etc. The equality operator (==) falls under a maybe.

In my opinion, mathematical operator overloading isn't critical. You may have defined a type such as

type Money int64

and uses it all over the place such as ..

var sum Money = 10000
sum += 5000

When later you change Money into this:

type Money struct {
    CurrencySymbol string
    Amount int64
}

The existing code with mathematical operators will just break and the compiler will refuse to compile. This allows you to conveniently fix the affected code. The same cannot be said with equality operators.

Let's take the Money example above, and it is used all over the place such as ..

if myMoney == herMoney {
    //do something
}

and later we changed money into something like..

type Money struct {
    CurrencySymbol string
    Amount int64
    ExchangeRate int64 //exchange rate should be ignored in equality comparison. 
        //JPY 10000 should be equal to JPY 10000 regardless of their original purchase cost.
} 

The existing code will still compile, but it will introduce a subtle bug. Hunting down the affected code isn't trivial. Searching for every occurrence of == operator is ridiculous.

Hence, in my opinion, #27605 is more about ergonomics, while this proposal is more about the language's flexibility when dealing with design myopia and refactoring.

In addition, I don't agree with having too many special methods to overload these operators, as this will take away good method names from the users. #27605 lists way too many operators to overload. Hence, in this proposal, I limit those to only Equal and Clone. #27605 does not mention Copy/Clone (perhaps because there is no specific operator for copying?).

#21604

#21604 is my old proposal. I had forgotten all about it. #21604 discussed about constructor overloading, copy/clone override, and type inheritance.

The copy/clone override part is essentially the same as this proposal's copy/clone suggestion. #21604 does not mention user-defined equality override, which I think is important. After an extra one year of experience using Go, #21604's constructor and inheritance proposals aren't probably that important.

Closing

The idea for this proposal came up from my own work. Having to search through every equality comparison and copying mechanism every time there is a change in data types that affect their equality/copying mechanism, is tedious and error prone. No IDE is smart enough to detect those. So, some sort of fundamental language support would be really nice.

In Java and C#, you can just override the base object's Equal method and be done with it. In Go, there is no base object and no inheritance. In Go, if you have the foresight, in a new project, you may have provided the Equal and Clone methods and warned in the comment that the users should use the provided methods instead of the built-in operators. Still, this isn't elegant and somebody may not read the documentation.

Now what if you haven't had the foresight and there are new requirements (eg. new features) to an existing codebase? Now you have to refactor, replacing those existing == and copy mechanism with your custom equal/copy methods. I did that in my work and there are still subtle bugs that creep months later. It gets even hard to detect when it is buried deep inside your business logic (when some decisions have to be made based on the equality comparison).

I support the idea of limiting copying allocation (many user-defined types are invalid on copy) but not redefining it via implicit copy constructor.

I'm drafting a proposal re default initializers on user-defined types, for both original & copying allocation.

BTW, these are the cases of copying allocation; assignment is a different case:

c := v
func(c T){}(v)
[]T{v}
append([]T{}, v)
[1]T{v}
struct{c T}{v}
map[K]T{k: v}
m[k] = v /*new k*/

Although this proposal is simpler than #21604, the same counter-arguments apply. We are not going to make this change.