Template parameters (and locals) are unintuitively affected by endianness

[BobSmun]

import std.io;
struct Test<auto t> {
    std::print("{}", t);
    u32 a = t;
};

le Test<5> test1;
be Test<5> test2;

std::print("{} {}",test1,test2);

results in:

I: 5
I: 5
I: bitfield Test { a = 5, t = 5 } bitfield Test { a = 83886080, t = 6646139978924579364519035301401722880 }

Inside the template, the parameter is read the same way (both being 5). This works as expected and allows consistent used for e.g. bitfield lengths.

However, the endianness seems to take effect when reading the template parameters (and locals) from outside the template. This makes it difficult to determine what they were, such as from a format function

[BobSmun]

A work around for this:

If any of the template parameters are guaranteed to always be smaller (or larger) than its endian flipped value, then both endian orderings can be compared to detect which was applied and allow for a way to deal with it. For example, template parameters have a type of auto - a 128bit value. If practical usage limits the value to be at most 64bit, then you would be able to confidently recover that value with this approach

If there are multiple template parameters / locals to fix-up, then only one of them needs to be checked and the result of its comparison can be used to correct the others

If none of the template parameters are guaranteed to always be smaller (or larger), then a default parameter can be added (e.g. via a using statement), using a known value that differs based on endian, to identify the appropriate endian to read the values as