Почему std::ssize принудительно устанавливается на минимальный размер для его типа размера со знаком?

Контейнеры, которые преднамеренно определяют размер uint16_t и, как известно, никогда не превышают 32 767 элементов, по-прежнему будут вынуждены использовать больший тип, чем требуется.

Это не похоже на то, что контейнер хранит размер как этот тип. Преобразование происходит через доступ к значению.

Что касается встроенных систем, программисты встроенных систем уже знают о склонности C++ к увеличению размера небольших типов. Поэтому, если они ожидают, что тип будет int16_t, они пропишут это в коде, потому что в противном случае C++ может просто повысить его до int.

Кроме того, не существует стандартного способа узнать, какой размер диапазона «заведомо никогда не превышается». decltype(size(range)) это то, о чем вы можете попросить; диапазоны размеров не требуются для обеспечения функции max_size. Без такой возможности самое безопасное предположение состоит в том, что диапазон, тип размера которого равен uint16_t, может принимать любой размер в пределах этого диапазона. Таким образом, размер со знаком должен быть достаточно большим, чтобы сохранить весь этот диапазон в виде значения со знаком.

Ваше предложение в основном состоит в том, что любой вызов ssize потенциально небезопасен, поскольку половина любого диапазона size не может быть правильно сохранена в возвращаемом типе ssize.

Контейнеры, которые используют размер по умолчанию size_t на 32-разрядных платформах, но которые, тем не менее, содержат элементы размером от 2 до 4 миллиардов, столкнутся с той же проблемой, что и выше.

Предполагая, что ptrdiff_t допустимо не быть 64-битным целым числом со знаком на таких платформах, действительного решения этой проблемы не существует. Так что да, будут случаи, когда ssize потенциально небезопасен.

ssize в настоящее время потенциально небезопасен в тех случаях, когда невозможно быть в безопасности. Ваше предложение сделает ssize потенциально небезопасным во всех всех случаях.

Это не улучшение.

И нет, просто утверждение/проверка контракта не является жизнеспособным решением. Смысл ssize состоит в том, чтобы заставить for(int i = 0; i < std::ssize(rng); ++i) работать без жалоб компилятора на несоответствие знаковых/беззнаковых. Чтобы получить утверждение из-за сбоя преобразования, которого не должно было произойти (кстати, его нельзя исправить без использования std::size, чего мы пытаемся избежать), который в конечном итоге не имеет отношения к вашему алгоритму ? Это ужасная идея.

если бы это было реализовано так, как я предложил, то этот код был бы Just Work™:

Оставим в стороне вопрос о том, как часто пользователь будет писать этот код.

Причина, по которой ваш компилятор будет ожидать/требовать от вас использования приведения, заключается в том, что вы запрашиваете опасную по своей сути операцию: вы потенциально теряете данные. Ваш код "Just Works™" работает только в том случае, если текущий размер соответствует int16_t; что делает преобразование статически опасным. Это не то, что должно происходить неявно, поэтому компилятор предлагает/требует, чтобы вы явно запросили это. И у пользователей, смотрящих на этот код, появляется большое бельмо на глазу, напоминающее им, что делается опасная вещь.

Это все к лучшему.

Видите ли, если предлагаемая вами реализация ведет себя так, как ведет себя ssize, то это означает, что мы должны рассматривать каждое использование ssize как столь же опасное по своей сути, как компилятор рассматривает вашу попытку неявного преобразования. Но в отличие от static_cast, ssize маленький и его легко пропустить.

Опасные операции должны быть обозначены как таковые. Так как ssize маленький и его трудно заметить по замыслу, он должен быть максимально безопасным. В идеале он должен быть таким же безопасным, как size, но в противном случае он должен быть небезопасным только в той степени, в какой его невозможно сделать безопасным.

Пользователи не должны смотреть на использование ssize как на что-то сомнительное или сбивающее с толку; они не должны бояться использовать его.