Thread: Overload the..bool operator..?

There is nothing "additional" about the conversion that you are talking about.

O_o

What? If you have two possibilities and add another... that's an additional possibility.

Actually, no, the if(some_instance) syntax [...] wording in N2437.

Or you are over-reading. It is as simple as that. Still, the wording has changed drastically between revisions and I get how one might interpret the current wording as allowing for this special case of 'operator bool' ignoring 'explicit' in certain contexts. (Though I interpret this revision as intentionally disallowing this special case while prevent implicit conversions to unrelated types in certain contexts.) This doesn't change much; the explicit conversion operators still only helps to solve one real problem--a naming issue. (The special case for 'bool', if it exists, actually does solve a few problems.)

As for CornedBee and Wikipedia... unless CornedBee is one of the authors or has directly spoken to one of them he is no more able of knowing the intent than you or I. That said, if he is one: further alter the wording to disassociate the "boolean conversion" from a normal "implicit conversion".

Soma

That's true. Now, stop being [...] same thing differently.

Funny. I think we are in complete agreement. I'm just adding a little more than what you are saying. See the source below for a simple and maybe surprising characteristic of marking a particularly problematic conversion explicit. (For full effect remove the explicit keyword and try again. Most programmers are still surprised by it. This is just the most obvious example.) What we both say: marking a single conversion explicit means that it isn't an option in implied circumstances. (I'm ignoring the possibility of a special 'bool' case.) I'm just saying that, like constructors, the compiler may find a way to make the implied conversion through other means even if the relevant source or target is marked as being an explicit conversion. (This was actually the intended consequence even if it does cause problems.) Or, in other words, marking a certain conversion with explicit prevents it from causing problems related to overload resolution in the face of... secondary--^_^--unrelated conversions.

Yes, I think that your [...] conversion with if (a).

I hope my interpretation is correct. It lays the groundwork for a stronger type system in the future.

Initially, I was convinced [...] and converts to an int.

This is what I was talking about in "Anyway, they, the [...] those same examples.".

Indeed, hence I notified [...] you wish to.

When you alerted me to the current wording allowing for the possibility of the intended special 'bool' behavior I reread CornedBee's comments. I've just assumed he was under the same impression as you. In the context of such special behavior his comments make a lot more sense.

Soma

Code:

#include <iostream>

struct test
{
  explicit test(int)
  {
    std::cout << "EXPLICIT!\n";
  }
  test(double)
  {
    std::cout << "IMPLIED!\n";
  }
};

void tester(const test&)
{
  std::cout << "TEST!\n";
}

int main()
{
  tester(1);
}