¿Es el lenguaje seguro-bool obsoleto en C ++ 11?

Esta respuesta de @R. Martinho Fernandes muestra que el lenguaje seguro-bool aparentemente está obsoleto en C ++ 11, ya que puede ser reemplazado por un simple

explicit operator bool() const; 

de acuerdo con la cita estándar en la respuesta §4 [conv] p3 :

Una expresión e puede convertirse implícitamente en un tipo T si y solo si la statement T t=e; está bien formado, para alguna variable temporal inventada t (§8.5). Ciertas construcciones de lenguaje requieren que una expresión se convierta en un valor booleano. Se dice que una expresión e aparece en dicho contexto se convierte contextualmente a bool y está bien formada si y solo si la statement bool t(e); está bien formado , para alguna variable temporal inventada t (§8.5).

La parte resaltada muestra claramente el “molde explícito implícito” (llamado “conversión contextual” en el estándar) como @R. Martinho lo dijo.

Los “constructos del lenguaje ciertos” que requieren que el “molde explícito implícito” parezca ser el siguiente:

  • if , while , for ( §6.4 [stmt.select] p4 )
  • operadores lógicos binarios && y || ( §5.14 [expr.log.and/or] p1 para ambos)
  • el operador de negación lógica ! ( §5.3.1 [expr.unary.op] p9 )
  • operador condicional ?: ( §5.14 [expr.cond] p1 )
  • static_assert ( §7 [dcl.dcl] p4 )
  • noexcept ( §15.4 [except.spec] p2 )

¿Nuestra suposición en el título es correcta? Espero que no hayamos pasado por alto los posibles inconvenientes.

Sí. Este es el ejemplo de problemas con solo tener conversiones implícitas definidas por el usuario y los operadores explícitos de conversión definidos por el usuario prácticamente se inventaron debido a este problema y para reemplazar todas las cosas seguras con algo mucho más limpio y más lógico.

Yo no lo llamaría “obsoleto”. No todos están dando el salto a C ++ 11 (ni siquiera 1 año de edad) hasta el momento. E incluso si hubiera una buena cantidad de codificadores, la capacidad de mantener el código compatible con versiones anteriores sería imprescindible, teniendo en cuenta que este tipo de expresiones idiomáticas parece más sensato para las bibliotecas que para los progtwigs propiamente dichos.