¿Por qué se introdujo std :: ssize () en C ++ 20?

C ++ 20 introdujo la std::ssize()función gratuita de la siguiente manera:

template <class C>
    constexpr auto ssize(const C& c)
        -> std::common_type_t<std::ptrdiff_t,
                              std::make_signed_t<decltype(c.size())>>;

Una posible implementación parece utilizar static_castpara convertir el valor de retorno de la size()función miembro de cl ass C en su contraparte firmada.

Dado que la size()función miembro de C siempre devuelve valores no negativos, ¿por qué alguien querría almacenarlos en variables firmadas? En caso de que uno realmente quiera, es una cuestión de simple static_cast.

¿Por qué se std::ssize()introduce en C ++ 20?

La justificación se describe en este documento . Una cita:

Cuando se adoptó span en C ++ 17, se utilizó un entero con signo tanto como índice como como tamaño. En parte, esto fue para permitir el uso de "-1" como valor centinela para indicar un tipo cuyo tamaño no se conocía en el momento de la compilación. Pero tener un contenedor STL cuya función size () devolvía un valor firmado era problemático, por lo que se introdujo P1089 para "solucionar" el problema. Recibió el apoyo de la mayoría, pero no el margen de 2 a 1 necesario para el consenso.

Este documento, P1227, fue una propuesta para agregar funciones no miembro std :: ssize y miembro ssize (). La inclusión de estos haría que cierto código sea mucho más sencillo y permitiría evitar la falta de firma no deseada en los cálculos de tamaño. La idea era que la resistencia a P1089 disminuiría si ssize () estuviera disponible para todos los contenedores, tanto a través de std :: ssize () como como funciones miembro.

Gratuitamente robada de Eric Niebler:

'Unsigned types signal that a negative index/size is not sane'fue la sabiduría predominante cuando se diseñó el STL por primera vez. Pero, lógicamente, un recuento de cosas no tiene por qué ser positivo. Es posible que desee mantener un recuento en un entero con signo para indicar el número de elementos agregados o eliminados de una colección. Entonces me gustaría combinar eso con el tamaño de la colección. Si el tamaño de la colección no está firmado, ahora me veo obligado a mezclar aritmética firmada y no firmada, que es una granja de errores. Los compiladores advierten sobre esto, pero debido a que el diseño del STL obliga a los programadores a entrar en esta situación, la advertencia es tan común que la mayoría de la gente la apaga. Es una pena porque esto esconde errores reales.

El uso de entradas sin firmar en interfaces no es la bendición que mucha gente cree que es. Si por accidente un usuario pasa un número ligeramente negativo a la API, de repente se convierte en un gran número positivo. Si la API hubiera tomado el número como firmado, entonces puede detectar la situación afirmando que el número es mayor o igual a cero.

Si restringimos nuestro uso de entradas sin firmar a la alteración de bits (por ejemplo, máscaras) y usamos entradas firmadas en cualquier otro lugar, es menos probable que ocurran errores y es más fácil detectarlos cuando ocurren.