NFD

Snippet from NFD:commit:ba9e4a4097726ea15a43d6acd7dc89e6664f8723 :

template<typename A>
A
getAvailableInterfaceIp(bool wantLoopback = false, bool needMulticast = false);

I'm not particularly happy with the two boolean arguments of getAvailableInterfaceIp()... they're not very self-descriptive at the call sites.

One solution is:

enum AvailableInterfaceFlags {
  AVAILABLE_INTERFACE_NONE = 0,
  AVAILABLE_INTERFACE_LOOPBACK = (1 << 0),
  AVAILABLE_INTERFACE_MCAST = (1 << 1)
};

template<typename A>
A
getAvailableInterfaceIp(AvailableInterfaceFlags flags);

Junxiao Shi wrote:

One solution is:

enum AvailableInterfaceFlags {
  AVAILABLE_INTERFACE_NONE = 0,
  AVAILABLE_INTERFACE_LOOPBACK = (1 << 0),
  AVAILABLE_INTERFACE_MCAST = (1 << 1)
};

Is this powerful enough though? I think we actually need 3 states for each network interface trait:

• yes, the trait must be present
• no, the trait must not be present
• don't care, the trait can be present or not, it doesn't matter

Reply to note-4:

It's as powerful as two booleans.

The complaint quoted in note-3 is about code readability, not about flexibility.

Absolutely. But since we're talking about the API, I wanted to go one step further and make it more flexible.

Also note that the two booleans in the current patch are named differently because they have different semantics when their values are set to false.

flexibility == complexity

Current use cases do not need flexibility, but only need readability.