Дизайн и эволюция constexpr в C++

тут я не понял последний пример - почему ui.reset() для const unique_ptr& OK? Это ведь иммутабельный объект.

Я закомментировал строку с ui.reset(), имея в виду, что эта строка не скомпилируется, но сейчас вижу, что текущий вид сбивает с толку. Спасибо, поменяю!

Плюс к тому, я не совсем понял как propconst должен решить проблему constexpr p = make_unique<int>(); В идеале должна выделиться compile-time память под мутабельный в рантайме int.

Нет, как раз вся задумка в том, чтобы этот int был наглухо иммутабельный в рантайме.

По задумке авторов предложения, non-transient память должна быть разрешена, только если никаким образом нельзя получить к какой-то ее части mutable-доступ (без const_cast и пр. хаков). Ясно что объект const unique_ptr<int> недостаточно силён, чтобы это гарантировать.

Смысл попытки введения propconst в том, чтобы усилить выразительность языка, и гарантировать иммутабельность всего, что нагенерировалось в constexpr. Объект типа const unique_ptr<int propconst> смог бы это гарантировать.

Тем не менее, предложение еще в разработке, и финальный результат (non-transient память) мы увидим в С++26 или дальше, потому что feature freeze для C++23 происходит в 2021 году.

не шибко то и уклончиво - запись в const объект всегда ведет к UB. А const_cast лишь преобразует типы ссылок/указателей.

Перечитал еще раз стандарт - да, так и есть, const_cast "can produce UB" лишь постольку, что может являться "посредником" для записи в const-объект. Неоднозначностей вроде нет.

Например, в микроконтроллерах STM есть Bit Banding (атомарная модификация отдельных битов), который полезен для модификации некоторых регистров, но он поддерживается не во всем адресном пространстве, т.е. по хорошему нужно делать валидацию чтобы не дебажить потом часами устройство из-за одной опечатки.
Но валидация во время выполнения впустую тратит процессорное время т.к. в большинстве случаев нужный адрес известен уже на этапе компиляции, а самое главное, валидация занимает место во flash памяти, которой зачастую не так много как хотелось бы.
В данном случае constexpr подходит просто идеально, позволяя абсолютно бесплатно выполнить вычисление нужного адреса и его валидацию еще на этапе компиляции.
PS: На мой взгляд constexpr - фича крайне полезная, в моем случае она позволила убрать кучу проверок и вычислений из рантайма и уменьшить объем прошивки примерно на 20%.

template<uint32 address, uint32 bitMask>
constexpr uint32 GET_BIT_BAND_ADDR()
{
	// Области памяти поддерживающие bit-banding
	constexpr uint32 ONE_MEGABYTE = 0xFFFFC;
	constexpr mem_region sram_area = mem_region(SRAM_BASE, SRAM_BASE + ONE_MEGABYTE);
	constexpr mem_region periph_area = mem_region(PERIPH_BASE, PERIPH_BASE + ONE_MEGABYTE);
	static_assert(sram_area.contains<address>() || periph_area.contains<address>(), "Invalid address");
	
	// Проверяем что установлен только один бит
	static_assert(IsPowOf2<bitMask>(), "Invalid bitMask");

	constexpr auto bitNumber = LSB_Number<bitMask>();
	uint32 bitAddress = 0;
	if (sram_area.contains<address>())
	{
		constexpr auto bitBandBaseAddress = SRAM_BASE + 0x2000000;
		bitAddress = bitBandBaseAddress + (address - SRAM_BASE) * sizeof(uint32) * 8 + bitNumber * sizeof(uint32);
	}
	if (periph_area.contains<address>())
	{
		constexpr auto bitBandBaseAddress = PERIPH_BASE + 0x2000000;
		bitAddress = bitBandBaseAddress + (address - PERIPH_BASE) * sizeof(uint32) * 8 + bitNumber * sizeof(uint32);
	}
	return bitAddress;
}

Это перевод инициализации во время работы программы в инициализацию на этапе компиляции. Пример constexpr, который может находиться почти в каждом .cpp файле:

constexpr std::string_view HELLO_WORLD = "Hello world";

Если бы вместо constexpr был const, то этот объект построился бы в старте работы программы до вызова int main(). В больших программах таких объектов много, до нескольких тысяч.

Также в compile-time строить прочие простые объекты: контейнеры (пока не STL), регулярные выражения.