Does D support middle endianness?

[Jonathan M Davis]

On Sunday, June 29, 2025 8:46:03 PM Mountain Daylight Time Valentino Giudice via Digitalmars-d wrote:
> The only reference I found was this thread from 11 years ago:
> https://forum.dlang.org/post/mailman.1953.1380926372.1719.digitalmars-d@puremagic.com
>
> I'd argue that if there aren't many middle endian architecture,
> it'd be worth not supporting them, in exchange for only having to
> deal with two byte orders (rather than all possible
> permutations), so the specification should mandate that either
> LittleEndian or BigEndian be set to true.

LittleEndian and BigEndian are version identifiers, not values which are
true or false. If we had a system that we supported which was middle endian,
then we'd need a version identifier for that, and there would be some code
that would need to be updated to use that version identifier, but we don't
have to worry about that unless / until we add support for such a system.

And the only place that I'm aware of where there's any value used as opposed
to a version identifier is std.system.Endian, which is an enum for
endianness with the idea that if a runtime value were needed for some
reason, it could be used

https://dlang.org/phobos/std_system.html#.Endian

So, if we were supporting a system which had endianness other than big or
little, then we'd need to add it to that enum, but that's never come up, and
realistically, code that deals with endianness normally would just use the
appropriate version identifier anyway.

So, we really don't need to worry about middle endian system support. If /
when we ever do add support for such a system, we can worry about it then,
and it wouldn't really simplify anything to say that we're not planning on
supporting such systems. The only gotcha that I'm aware of is that if you
use else with version identifiers - e.g.

version(LittleEndian)
{
}
else
{
}

with the assumption that only big and little endian exist, then there could
be problems if / when we ever added support for a middle endian system, and
arguably, it's more correct to do something like

version(LittleEndian)
{
}
else version(BigEndian)
{
}
else
    static assert(false, "Unsupported endianness");

but that really only affects libraries, not the language itself, and so
little code has to worry about endianness that it doesn't matter much. And
as a general rule, it's usually best practice to use a static assertion like
that with the else branch of a version statement anyway.

So, I think that you're worrying about a total non-issue. We really don't
gain anything by mandating anything about future support for other types of
endianness, and the fact that we could theoretically add support for other
types of endianness at some point in the future really doesn't put any sort
of burden on us right now that could be removed by saying that we're never
going to support other types of endianness.

- Jonathan M Davis