Por que std :: ssize () foi introduzido em C ++ 20?

C ++ 20 introduziu a std::ssize()função livre conforme abaixo:

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

Uma possível implementação parece usar static_cast, para converter o valor de retorno da size()função-membro de cl ass C em sua contraparte assinada.

Visto que a size()função-membro de C sempre retorna valores não negativos, por que alguém iria querer armazená-los em variáveis ​​com sinal? Caso se queira mesmo, é uma questão de simples static_cast.

Por que é std::ssize()introduzido no C ++ 20?

A justificativa é descrita neste artigo . Uma citação:

Quando span foi adotado em C ++ 17, ele usou um inteiro com sinal tanto como índice quanto como tamanho. Em parte, isso era para permitir o uso de "-1" como um valor sentinela para indicar um tipo cujo tamanho não era conhecido no momento da compilação. Mas ter um contêiner STL cuja função size () retornasse um valor assinado era problemático, então P1089 foi introduzido para "consertar" o problema. Recebeu o apoio da maioria, mas não a margem de 2 para 1 necessária para o consenso.

Este artigo, P1227, foi uma proposta para adicionar funções não membros std :: ssize e membro ssize (). A inclusão desses tornaria certos códigos muito mais simples e permitiria a prevenção de não sinais indesejados em cálculos de tamanho. A ideia era que a resistência a P1089 diminuiria se ssize () fosse disponibilizado para todos os contêineres, tanto por meio de std :: ssize () quanto como funções-membro.

Roubado gratuitamente de Eric Niebler:

'Unsigned types signal that a negative index/size is not sane'era a sabedoria predominante quando o STL foi projetado pela primeira vez. Mas logicamente, uma contagem de coisas não precisa ser positiva. Posso querer manter uma contagem em um inteiro assinado para denotar o número de elementos adicionados ou removidos de uma coleção. Então, eu gostaria de combinar isso com o tamanho da coleção. Se o tamanho da coleção não é assinado, agora sou forçado a misturar aritmética assinada e não assinada, que é um bug farm. Os compiladores alertam sobre isso, mas como o design do STL praticamente força os programadores a essa situação, o aviso é tão comum que a maioria das pessoas o desativa. É uma pena, porque esconde bugs reais.

O uso de ints não assinados em interfaces não é a vantagem que muitas pessoas pensam que é. Se por acidente um usuário passa um número ligeiramente negativo para a API, de repente ele se torna um grande número positivo. Se a API considerou o número assinado, ela pode detectar a situação afirmando que o número é maior ou igual a zero.

Se restringirmos nosso uso de ints não assinados à manipulação de bits (por exemplo, máscaras) e usarmos ints assinados em qualquer outro lugar, é menos provável que ocorram bugs e sejam mais fáceis de detectar quando eles ocorrem.