I think I'd rather just make maps shrinkable.

I think both cases would be useful. Allowing cap() on maps would make Go more consistent and easier to learn, even if it is only informative.

And making maps shrink automatically is also a useful feature but that is what issue #20135 is for.

It's hard to explain what cap means at all. It's a rough estimate of the size of the underlying storage and that's about it.
Unlike cap on slices and chans, it is not a guarantee about being able to store that much without resizing / blocking.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

No change in consensus, so declined.
— rsc for the proposal review group

I couldn't find the discussion that Russ mentioned (but I think I know the gist). I still think this is a worthwhile idea. An alternative would be to add a builtin function as part of the unsafe "package".

@AndrewWPhillips Sorry, this proposal is closed. We aren't going to reopen it without new information that we didn't previously consider.

I don't know if this meets the threshold for "new information" sufficient to reopen the issue, but I've just run into this in the following scenario....

Developing a module which internally uses a map in a struct type that is initialised using a func where the caller indicates a desired capacity for the contained map. Without the ability to determine the capacity of the newly initialised map, it is not possible to write a unit test to verify that the initialisation function returned a correctly initialised struct.

For all other types where make() supports establishing an initial capacity, cap() is available to determine the capacity. A map being the only exception is perplexing and frustrating but, more seriously and significantly, is an impediment to testing.

I cannot conceive of any problem that addressing this omission/exception would create and would appreciate consideration being given to re-opening the proposal.

Я не знаю, соответствует ли это порогу «новой информации», достаточному для повторного открытия проблемы, но я только что столкнулся с этим в следующем сценарии....

Разработка модуля, который внутренне использует карту в типе структуры, инициализируемой с помощью функции, где вызывающая сторона указывает желаемую емкость содержащейся карты. Без возможности определить емкость вновь инициализированной карты невозможно написать модульный тест, чтобы убедиться, что функция инициализации вернула правильно инициализированную структуру.

Для ** всех ** остальных типов, где make()поддерживает создание первоначальной мощности, cap()доступен для определения емкости. А mapбудучи единственным исключением, это сбивает с толку и разочаровывает, но, что более серьезно и важно, это является препятствием для тестирования.

Я не могу себе представить какую-либо проблему, которую могло бы создать устранение этого упущения/исключения, и был бы признателен за рассмотрение возможности повторного рассмотрения предложения.

I uphold