tbb::filter::filter(bool)

[Frankel__Justin]

tbb::filter should provide a nested enumerated type with two values: serial and parallel (or similar). Then, the constructor should have a parameter of that type rather than bool. That makes a derivate constructor look like this:

a_filter::a_filter(/* parameters */)
: tbb::filter(serial)
{
}

The use of "serial" and "parallel" is more obvious than are "true" and "false."

[robert-reed]

Sure, "serial" and "parallel" are more descriptive values for the state. I've got code that uses the current interface and I don't know how much more application code might alreadyrely on it--TBB hasbeen available to the public for a year now. Maybe the interface could evolve that way, but I think it would also have to maintain the boolean version for compatibility.

[Frankel__Justin]

I had no idea TBB had been out that long! Backward compatibility is certainly an issue, in that case. I would be inclined to add the enumerated type, overload the constructor, and deprecate the old constructor. That gives folks time to begin using the new constructor without breaking old code, and yet gives them warning that they should change their old code as soon as practicable.

[Alexey-Kukanov]

Actually, the same "syntactic sugar" can be achieved if we define two static bool constants in tbb::filter:

static const bool serial = true;
static const bool parallel = false;

And there is no need to change the interface, unless we want to extend filter types into another dimension beyond "serial or parallel".

[Frankel__Justin]

Quite right. I had thought of that, but I rejected that approach because the compiler doesn't enforce it. The approach I advocated, though it does mean deprecating an interface, leads to an eventual point when the compiler can enforce clarity.

[ARCH_R_Intel]

When I was designing the original filter interface, I wavered between using the bool argument ordefining an enum {parallel,serial}. When in doubt, I usually go for simplicity, and so when with the bool. I'll take the comment as a vote for the enum :-) Yes, overloading and deprecation would bea practical way to migrate TBB towards using the enum if there is a consensus for the enum.