Reopen #573

[nf-brentsaner]

Describe the bug

#573 should be reopened.

The required API behavior as the suggested "solution" is a clear violation of Go best practices, is needlessly restrictive, and is broken by design - types should be able to marshal whether they are used as a pointer or value on a field.

To Reproduce

(See #573)

Expected behavior
(See #573)

Screenshots
N/A

Version Variables

• Go version: 1.25.6
• go-yaml's Version: v1.19.2

Additional context

1. bug: MarshalYAML does not get called #573 requires a value receiver if the containing struct field is a value and not a pointer, and vice versa.
2. This means one cannot use both value fields and pointer fields for the same type, as you cannot define the same method name for the same type as a value receiver vs. pointer receiver. THIS IS BROKEN BEHAVIOR. I can think of no other library that has this quite frankly absolutely insane requirement/behavior.

Additionally:

1. An UnmarshalYAML method must, by definition, be a pointer receiver (otherwise it cannot modify the value)
2. As stated before, this is not only broken design but also clearly violates Go guidelines:

Next is consistency. If some of the methods of the type must have pointer receivers, the rest should too, so the method set is consistent regardless of how the type is used. See the section on mthod sets for details.

(emphasis added)

This violates Go best practices and is extremely anti-pattern, and is in direct conflict with expected behavior based on both other third-party Marshal* functionality and stdlib Marshal* functionality.

[wrouesnel]

Agree with this - it's extremely surprising behavior and leads to unhappy surprises.

IMO in general if there's an intuitive behavior, it should happen - i.e. I'm MarshalingYAML, there's a usable MarshalYAML method and there's never any reason I'd want something else to happen.

[goccy]

OK, I will see this