On 12/03/2015 06:13 AM, Vladimir Panteleev wrote:
You said that "at the end of the day there's documentation". I would argue that at least in this case, it may not be enough. Consider, for example, a hypothetical user type "Pack", which takes a tuple/struct and automatically arranges the fields into a struct such that space is used optimally (e.g. all bools are clumped together into a bitfield, enums are only given as much bits as their .max needs, etc.). Pack only needs to know one property of each field: how many bits it really needs, and as such, it might elect to be agnostic of what a pointer is. If it uses std.bitmanip.bitfields as its backend, it will happily pack a pointer at its user's request, and the user will never see the pointer warning in Pack's documentation. And yes, although it's easy to point the finger at users and say "ha ha, it's your own fault, you did not RTFM", I think we should strive for better than that.
I understand how you feel but I really don't know what else to do, which makes the entire discussion somewhat theoretical. At the end of the day Pack must document its own behavior and its users should have some notion of its characteristics. If Pack wishes to disallow pointers that can be easily done with static introspection. If it doesn't have enough information, it's poorly designed - it can't just take any bits and shove them in any way. -- Andrei
