Conversation
| an accessible concrete non-virtual member with a "matching" signature is inherited. | ||
| Two members are considered matching if they have the same | ||
| signature or would be considered "hiding" in an inheritance scenario. | ||
| It is an error for a member of a record to be named "Clone". |
There was a problem hiding this comment.
Did we really decide to disallow all members named Clone, or should we allow methods named Clone as long as they have parameters?
There was a problem hiding this comment.
We explicitly discussed methods and fields in LDM ("Clone" fields should be disallowed). For nested types, I chatted with Jared offline and I think we'll want the same behavior.
There was a problem hiding this comment.
I don't believe that particular variant of the question was raised in LDM. Personally, I'd prefer to disallow all members (named Clone), just in case we end up wanting to add some kind of parameter list to possibly support only cloning if an initer will actually change a field, but it's a followup we could raise with the LDM if we want to clarify.
|
Out of curiosity is there a reason to disallow |
|
@HaloFour We're reserving it as we may allow customization of the clone method, or implementation on non-record types in the future. Reserving that name keeps some options open. Notes: https://github.com/dotnet/csharplang/blob/master/meetings/2020/LDM-2020-07-01.md#Confirming-unspeakable-Clone-method-implications |
|
ah ok, gotcha. I assume that this means that a record cannot implement |
|
Correct. That's a good test scenario (I'll add to my PR). |
No description provided.