Constants as Capability Enum

[Latrasis]

It would seem like having capabilities as part of a general 'Cabability' enum type - instead of having a large list of constants. Thoughts?

[gcmurphy]

Agree. I can't remember why I switched to const new types, but it doesn't seem that it was necessary / or really worth it.

Let me know what you think of this commit ae09955.

Do you think I should move to camel case for the Capability Enum?

[Latrasis]

Much better, but having a Capability struct is a bit redundant, could you simply have Capability enum and impl methods on the enum instead?

[gcmurphy]

That's what the change did. It removed the Capability struct. There is a Capabilities struct which represents a set of Capabilities for a process etc if that's what you mean? Anyway this change is now in 0.2.0.

[Latrasis]

Sorry, yes I meant about replacing the Capabilities altogether. Is there are reason to have it - instead of a [Cabability; N] type and iterating over it?

[gcmurphy]

That struct exists to hold the libcap handle and ensure it is released properly etc. Originally I added it as I basically just wanted to wrap the libcap capi calls. But I'll look into how I could ditch it as it should provide a nicer interface.

[Latrasis]

In terms of naming, the CAP prefix for each Capability does seem a bit redundant. In rust, it's formal to have CAPS for const's and CamelCases for types. 👍

[vorner]

Capabilities are bit flags in the C API, would it make sense to actually use the bitflags crate?