Use EnumSet instead of a full-blown btreemap for the attributes

[jwiesler]

This minimal change reduces the size of Style from 32 bytes to 10 and removes allocations needed to construct a style. This also means the remainder of the API could become const. If you want me to do that please ping me and I will do it in this mr.

The semantics of a bitset differ from the btreemap in so far as the btreemap is in insertion order, but I think this does not matter for attribute codes being printed, however, please verify this. Maybe this can be fixed by reordering the enum members.

The EnumSetType derive automatically derives Copy, Clone, PartialEq and Eq which is why I had to remove them.

For the library used see enumset.

[djc]

This minimal change reduces the size of Style from 32 bytes to 10 and removes allocations needed to construct a style. This also means the remainder of the API could become const.

Which part of this matters to you (most), what is your use case/motivation for this PR?

IMO enumset is pretty large dependency for something low-level like console. In particular it pulls in all the proc-macro machinery which I would prefer to avoid.

Maybe a more minimal "manual" implementation of the same principles could make sense.

[jwiesler]

In short: Const API and no allocations/performance improvements.
Longer: I've been looking for a library that does this styling in an optimal way without first rendering the input to a string or something like this, which console does nicely by transparently implementing Debug and Display. However, e.g. a bold Style can't be stored in a constant, since it requires attr which is not const and this really doesn't have to be the case. Also storing this in a tree set on the heap seems overkill for this.

I could do a manual implementation with an u16 as storage (maybe 30-60 LOC), but that would make it harder for you to review :) Please tell me before I invest the time if you'd be willing to even merge this afterwards or under which constraints (e.g. no unsafe, ...).

[djc]

Happy to review 30-60 LoC of manual implementation, if it doesn't contain unsafe and doesn't bring in new dependencies.

(Maybe also look at the anstyle family of crates, including anstyle-stream.)

[jwiesler]

I looked at anstyle-stream and implemented it in 60 LOC (barely). There are more changes, I added two tests and made all functions I found const.

[djc]

Looks great, just a few small nits!

[djc]

I'm inclined to leave this out here and inline it into the one (library) callsite. What do you think?

[jwiesler]

I like it like this more, since bits would be a very opaque term on the calling site. But your call.

[jwiesler]

Phew: mutable references are not allowed in constant functions. That rust version 1.66 do be pretty old.

[djc]

Phew: mutable references are not allowed in constant functions. That rust version 1.66 do be pretty old.

Can probably just take self like the other methods?

[jwiesler]

True, I thought those were the attr() functions.

[djc]

This looks pretty good, I'll probably make some small tweaks.