Russ Cox

Based on the discussion above, this proposal seems like a **[likely accept](https://go.dev/s/proposal-status#likely-accept)**. — rsc for the proposal review group

No change in consensus, so **[accepted](https://go.dev/s/proposal-status#accepted)**. 🎉 This issue now tracks the work of implementing the proposal. — rsc for the proposal review group

This comes up so often that I think we should just add it. We can add a nice comment on it explaining that in many cases there may be better...

This proposal has been added to the [active column](https://go.dev/s/proposal-status#active) of the proposals project and will now be reviewed at the weekly proposal review meetings. — rsc for the proposal review...

Here is a concrete proposal. ``` package binary var NativeEndian nativeEndian type nativeEndian ... same implementation as big or little depending ``` We can't use a type alias for nativeEndian,...

@josharian's embedding approach looks good to me and seems to address @robpike's objection. Updated title to add the x/sys/cpu.IsBigEndian constant in the [concrete proposal](https://github.com/golang/go/issues/57237#issuecomment-1361852721).

Are there any remaining objections to this proposal?

> I regard also defining the CPU endianness as problematic, because CPUs like ARMv7 are able to support multiple endianness modes. For those CPUs the OS defines the endianness of...

Based on the discussion above, this proposal seems like a **[likely accept](https://go.dev/s/proposal-status#likely-accept)**. — rsc for the proposal review group

This proposal has been added to the [active column](https://golang.org/s/proposal-status#active) of the proposals project and will now be reviewed at the weekly proposal review meetings. — rsc for the proposal review...