options = options.SetFlag(Options.DoThis);
options = options.ClearFlag(Options.DoThat);

options = options.With(Options.DoThis).Without(Options.DoThat);
// или
options = options.Include(Options.DoThis).Exclude(Options.DoThat);

EnumCode.FlagUnset(options, nameof(options), Options.DoThis | Options.DoThat); // asserts that both flags are unset
EnumCode.AnyFlagUnset(options, nameof(options), Options.DoThis | Options.DoThat); // asserts that any flag cleared.

Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

(A|B).IsAnyFlagUnset(B|C|D) == true // C or D are unset
(A|B).IsFlagUnset(B|C|D) == false   // B is set

S>(A|B).IsAnyFlagUnset(B|C|D) == true // C or D are unset
S>

(B|C|D).Diff(A|B).Any()

S>(A|B).IsFlagUnset(B|C|D) == false   // B is set
S>

S>Вот тут не понял, но интересно. Можно подробее?

FileAccess SetFlag(this FileAccess left, FileAccess right, bool value)
            => value ? left | right : left & ~right;

DO understand and explicitly design for a broad range of developers with different programming styles, requirements, and skill levels.

CHRIS SELLS As a test of whether an API is "simple," I like to submit it to a test I call "client-first programming." If you say what your library does and ask a developer to write a program against what he or she expects such a library to look like (without actually looking at your library), does the developer come up with something substantially similar to what you've produced? Do this with a few developers. If the majority of them write similar things without matching what you've produced, they're right, you're wrong, and your library should be updated appropriately.

I find this technique so useful that I often design library APIs by writing the client code I wish I could write and then just implement the library to match that. Ofcourse, you have to balance simplicity with the intrinsic complexity of the functionality you're trying to provide, but that's what your computer science degree is for!

KRZYSZTOF CWALINA It is easy to design for users who are like you, and very difficult to design for somebody urdike you. There are too many APk that are designed by domain experts and, frankly, they are only good for domain experts. The problem is that most developers are not, will never be, and do not need to be experts in aU technologies used in modem applications.

KRZYSZTOF CWALINA We did not test the usability of the types in the System.IO namespace before shipping version 1.0 of the Framework. Soon after shipping, we received negative customer feedback about System.IO usability. We were quite surprised, and we decided to conduct usability studies with eight average VB developers. Eight out of eight failed to read text from a file in the 30 minutes we allocated for the task. We believe this was due in part to problems with the documentation search engine and insufficient sample coverage; however, it is clear that the API itself had several usability problems. If we had conducted the studies before shipping the product, we could have eliminated a significant source of customer dissatisfaction and avoided the cost of trying to fix the API of a major feature area without introducing breaking changes.

BRAD ABRAMS There is no more powerful experience to give an API designer a visceral understanding of the usability of his or her API than sitting behind a one-way mirror watching developer after developer get frustrated with an API he or she designed and ultimately fail to complete the task. I personally went through a full range ofemotions while watching the usability studies for System.IO that we did right after shipping version 1.0. As developer after developer failed to complete the simple task, my emotions moved from arrogance to disbelief, then to frustration, and finally to stringent resolve to fix the problem in the API.