sunfishcode commented on Issue #1299:
I'd like to suggest a different possible approach here: instead of different way to represent flags as integers, we format flags with human-readable names.
For example, instead of an
fdflagsvalue being '0b10001or0x11or041, we print it asappend|sync (0x11)`. Then most people will just read the names, and we can just have one formatting method.That will get pretty verbose with big flag words that frequently have many flags set, like
rights, but I propose as a first iteration, being overly verbose with flag names is still better than numbers that I have to mentally map to flag names :-). And as a second iteration, perhaps we could declareRIGHTS_REGULAR_FILE_BASEetc. in witx somehow (which we should probably do anyway), and then formatting code could compute which*_BASExor'd with the given flags word has the least hamming distance and print the base with difference, eg.tty&!write|tellor so.Thoughts?
sunfishcode edited a comment on Issue #1299:
I'd like to suggest a different possible approach here: instead of different way to represent flags as integers, we format flags with human-readable names.
For example, instead of an
fdflagsvalue being0b10001or0x11or041, we print it asappend|sync (0x11). Then most people will just read the names, and we can just have one formatting method.That will get pretty verbose with big flag words that frequently have many flags set, like
rights, but I propose as a first iteration, being overly verbose with flag names is still better than numbers that I have to mentally map to flag names :-). And as a second iteration, perhaps we could declareRIGHTS_REGULAR_FILE_BASEetc. in witx somehow (which we should probably do anyway), and then formatting code could compute which*_BASExor'd with the given flags word has the least hamming distance and print the base with difference, eg.tty&!write|tellor so.Thoughts?
kubkon commented on Issue #1299:
Oh, sounds intriguing! I like it! I'm not sure how easy it would be but I reckon it's worth a try!
github-actions[bot] commented on Issue #1299:
Subscribe to Label Action
This issue or pull request has been labeled: "w", "a", "s", "i"
To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.
alexcrichton commented on Issue #1299:
FWIW I think the
bitflagscrate in Rust does what @sunfishcode is mentioning, and it's pretty slick and would recommend having that here as well for the default.
kubkon commented on Issue #1299:
So I thought about using
bitflagscrate originally but it requires another dependency and it was awkward to work with previously, as the user ofwigglewould effectively be forced to includebitflagsas a dependency in the crate they’d usewigglein. Now, I haven’t checked if that’s still the case. If it’s not, than I’m all for using it as it would drastically simplify generation of a couple of data types (flags and ints in particular).
alexcrichton commented on Issue #1299:
Oh sure yeah to be clear I don't think we should use the
bitflagscrate directly, but just wanted to point out some prior art if it's helpful.
kubkon commented on Issue #1299:
Ah, gotcha! :-)
kubkon commented on Issue #1299:
@sunfishcode @alexcrichton Flags is now by default formatted similarly to how
bitflagscrate does it, namely,dsync|append (0x11). In case we're dealing with an empty set, we getempty (0x0). Because of this, anyOctal,LowerHex, etc., formatters are redundant now.Furthermore, while here, I've rewritten
EMPTY_FLAGSandALL_FLAGS(where the former means0x0and the latter is the union of all possible values) to beconst fn empty()andconst fn all()where the latter is an expanded union of primitive representation values out of a macro. This is again largely inspired by thebitflagscrate.
kubkon commented on Issue #1299:
\o/
Can you add a test in tests/flags.rs which does
.to_string()on some flags values and asserts that it produces the strings expected?Excellent suggestion, I've added a testcase for this just now :-)
Last updated: Dec 13 2025 at 19:03 UTC