Overload the..bool operator..?

Originally Posted by phantomotap

I intended to imply "disallow an additional conversion possibility separate from other implicit conversions in a given context". (Consider what happens when the explicit form from one type gets cozy with a non-explicit conversion from the other.)

I think that you should just change "additional" to "implicit". There is nothing "additional" about the conversion that you are talking about.

Originally Posted by phantomotap

The point is, for this exact use case, users will still have to deal with implicit conversion operators because they, the explicit conversion operators, don't really solve many problems. They just make the problems appear to vanish because they require the programmer to tell the compiler exactly what to do. If I don't mind doing 'if(bool(some_instance))' the explicit operators are fine, but if I need 'if(some_instance)' I still have to do the work because I can't use the explicit operators. (I chose this example because it was what the OP asked. This is really one of the least useful and least obtrusive cases.)

Actually, no, the if(some_instance) syntax would work with an explicit conversion function to bool. CornedBee just changed the Wikipedia C++0x article to clarify that point, and it appears that I did not read carefully enough into the proposed wording in N2437.

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

Originally Posted by phantomotap

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

That's true. Now, stop being so vague and detail what exactly are these "two possibilities" and "another". I suspect we are in general agreement but disagreeing because we see the same thing differently.

Originally Posted by phantomotap

Though I interpret this revision as intentionally disallowing this special case while prevent implicit conversions to unrelated types in certain contexts.

Yes, I think that your interpretation is viable, especially since the proposed amendment to section 12.3.2 did not include any such example even though the existing text demonstrates an implicit conversion with if (a). Initially, I was convinced that this was an example of precisely the kind of special case permitted, but overlooked the fact that the existing text has a class named X whose conversion function is (obviously) non-explicit and converts to an int.

Originally Posted by phantomotap

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.

Indeed, hence I notified you of the change in the Wikipedia text for you to read CornedBee's opinion and dispute it if you wish to.

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);
}