¿Cuál es la razón para no usar C ++ 17 [[nodiscard]] casi en todas partes en un nuevo código?

C ++ 17 introduce el [[nodiscard]]atributo, que permite a los programadores marcar funciones de manera que el compilador produzca una advertencia si el llamador descarta el objeto devuelto; se puede agregar el mismo atributo a un tipo de clase completo.

He leído sobre la motivación de esta característica en la propuesta original , y sé que C ++ 20 agregará el atributo a funciones estándar como std::vector::empty, cuyos nombres no transmiten un significado inequívoco con respecto al valor de retorno.

Es una característica genial y útil. De hecho, casi parece demasiado útil. En todas partes sobre las que leo [[nodiscard]], las personas lo discuten como si simplemente lo agregaran a algunas funciones o tipos seleccionados y se olvidaran del resto. Pero, ¿por qué un valor no descartable debería ser un caso especial, especialmente al escribir código nuevo? ¿No es un valor de retorno descartado típicamente un error o al menos una pérdida de recursos?

¿Y no es uno de los principios de diseño de C ++ que el compilador debería detectar tantos errores como sea posible?

Si es así, ¿por qué no agregar [[nodiscard]]su propio código no heredado a casi todas las voidfunciones que no funcionan y casi todos los tipos de clase?

Intenté hacer eso en mi propio código, y funciona bien, excepto que es tan terriblemente detallado que comienza a sentirse como Java. Parecería mucho más natural hacer que los compiladores adviertan sobre los valores de retorno descartados por defecto, excepto en los pocos otros casos en los que marca su intención ^[*] .

Como no he visto ninguna discusión sobre esta posibilidad en las propuestas estándar, entradas de blog, preguntas de Stack Overflow o en cualquier otro lugar de Internet, me falta algo.

¿Por qué esa mecánica no tendría sentido en el nuevo código C ++? ¿Es la verbosidad la única razón para no usar [[nodiscard]]casi en todas partes?

^{[*] En teoría, es posible que tengas algo así como un [[maydiscard]]atributo, que también podría agregarse retroactivamente a funciones como printfen implementaciones de biblioteca estándar.}

En el nuevo código que no necesita ser compatible con estándares más antiguos, use ese atributo siempre que sea razonable. Pero para C ++, [[nodiscard]]hace un mal defecto. Tu sugieres:

Parecería mucho más natural hacer que los compiladores adviertan sobre los valores de retorno descartados por defecto, excepto en los pocos otros casos en los que marca su intención.

Eso provocaría de repente que el código correcto existente emitiera muchas advertencias. Si bien dicho cambio podría considerarse técnicamente compatible con versiones anteriores, ya que cualquier código existente aún se compila con éxito, eso sería un gran cambio de semántica en la práctica.

Las decisiones de diseño para un lenguaje maduro existente con una base de código muy grande son necesariamente diferentes de las decisiones de diseño para un lenguaje completamente nuevo. Si este fuera un nuevo idioma, entonces la advertencia por defecto sería sensata. Por ejemplo, el lenguaje Nim requiere que los valores innecesarios se descarten explícitamente; esto sería similar a envolver cada declaración de expresión en C ++ con un reparto (void)(...).

Un [[nodiscard]]atributo es más útil en dos casos:

• si una función no tiene efectos más allá de devolver un cierto resultado, es decir, es pura. Si no se utiliza el resultado, la llamada es ciertamente inútil. Por otro lado, descartar el resultado no sería incorrecto.

• si se debe verificar el valor de retorno, por ejemplo, para una interfaz tipo C que devuelve códigos de error en lugar de arrojarlos. Este es el caso de uso principal. Para C ++ idiomático, eso será bastante raro.

Estos dos casos dejan un enorme espacio de funciones impuras que devuelven un valor, donde tal advertencia sería engañosa. Por ejemplo:

• Considere un tipo de datos de cola con un .pop()método que elimina un elemento y devuelve una copia del elemento eliminado. Tal método es a menudo conveniente. Sin embargo, hay algunos casos en los que solo queremos eliminar el elemento, sin obtener una copia. Eso es perfectamente legítimo, y una advertencia no sería útil. Un diseño diferente (como std::vector) divide estas responsabilidades, pero eso tiene otras desventajas.

  Tenga en cuenta que, en algunos casos, se debe hacer una copia de todos modos, así que gracias a RVO, la devolución de la copia sería gratuita.

• Considere interfaces fluidas, donde cada operación devuelve el objeto para que se puedan realizar más operaciones. En C ++, el ejemplo más común es el operador de inserción de flujo <<. Sería extremadamente engorroso agregar un [[nodiscard]]atributo a cada <<sobrecarga.

Estos ejemplos demuestran que hacer que el código idiomático de C ++ se compile sin advertencias bajo un lenguaje “C ++ 17 con no descarte por defecto” sería bastante tedioso.

Tenga en cuenta que su nuevo y brillante código C ++ 17 (donde puede usar estos atributos) aún puede compilarse junto con bibliotecas que se dirigen a estándares C ++ más antiguos. Esta compatibilidad con versiones anteriores es crucial para el ecosistema C / C ++. Por lo tanto, hacer que no descarte el valor predeterminado resulte en muchas advertencias para casos de uso típicos, idiomáticos, advertencias que no puede solucionar sin cambios de gran alcance en el código fuente de la biblioteca.

Podría decirse que el problema aquí no es el cambio de semántica sino que las características de cada estándar C ++ se aplican en un ámbito por unidad de compilación y no en un ámbito por archivo. Si / cuando algún estándar futuro de C ++ se aleja de los archivos de encabezado, dicho cambio sería más realista.

Razones por las que no lo haría [[nodiscard]]casi en todas partes:

1. (mayor :) Esto introduciría manera demasiado ruido en mis cabeceras.
2. (mayor :) No creo que deba hacer suposiciones especulativas sobre el código de otras personas. ¿Quieres descartar el valor de retorno que te doy? Bien, noqueate.
3. (menor :) Estaría garantizando incompatibilidad con C ++ 14

Ahora, si lo configura por defecto, obligaría a todos los desarrolladores de bibliotecas a obligar a todos sus usuarios a no descartar los valores de retorno. Eso sería horrible O los obligas a agregar [[maydiscard]]innumerables funciones, lo que también es horrible.

Como ejemplo: el operador << tiene un valor de retorno que depende de la llamada, ya sea absolutamente necesario o absolutamente inútil. (std :: cout << x << y, el primero es necesario porque devuelve la secuencia, el segundo no sirve para nada). Ahora compare con printf donde todos descartan el valor de retorno que está allí para la verificación de errores, pero luego el operador << no tiene verificación de errores, por lo que no puede haber sido tan útil en primer lugar. Entonces, en ambos casos, nodiscard sería simplemente perjudicial.