История изменений

Так вопрос и был риторическим. То есть, весь блок будет валиться с плохо отслеживаемой причиной.

Вы, видимо, о C++ наслышаны лишь поверхностно, поэтому вам кажется, что вопрос выглядит риторическим.

В некоторых местах в C++ можно получить исключение из-за действий, выполняемых самой языковой или библиотечной фичей. Например, при оборачивании лямбды в std::function или при создании новой короутины можно поймать bad_alloc и это вообще никак не будет связано с кодом, который пишет пользователь.

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

По моей ссылке

Есть конкретный пропозал по добавлению паттерн-матчинга в C++. На данный момент третья редакция: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1371r3.pdf

Но масштабируется по уровням абстракций это дело отвратительно.

Опять бездоказательные эмоции? Пример можно?

Любая относительно глобальная ячейка variant с непримитивным значением рано или поздно приходит к этому состоянию.

Бла-бла-бла. Хватит уже говно из вашей башки изливать. Есть конкретный пример? Если есть, то показывайте.

То есть, исключения обработаны, локальные ресурсы корректно высвобождены, но исключение было брошено при изменении variant

То что?

Если ваш код обеспечивает базовую гарантию, то экземпляр variant, который был поврежден при выбросе исключений подлежит либо уничтожению, либо должен получить новое значение. Точка.

Любое другое использование проблемного variant – это алгоритмическая ошибка программиста. А раз она допущена, то нет смысла рассматривать случаи, когда variant пошел в паттерн-матчинг и там не обработали ситуацию с отсутствием значения.

Если же в вашем коде строгая гарантия или nothrow-гарантия, то у вас не будет проблемного экземпляра variant.

Любой идентификатор для определения типа значения в tagged union.

Тогда мы возвращаемся к тому, о чем я вам уже говорил: в случае std::variant (или любого его аналога) вы в compile-time имеете список типов и какой-то «неожиданный» элемент в этом списке у вас появится не может.

Предлагаю сравнить с C#

От графомана с проблемами в логических цепочках подобного сравнения и стоило ожидать. Тут у нас как бы C++, нативный язык, где во главу угла ставится zero cost. А вы ему пытаетесь противопоставить язык со сборкой мусора, с неконтролируемыми программистом расходами на создание экземпляров reference types и т.д.

Так это один и тот же int!

Я там не вижу одного и того же int-а. Есть shared_ptr<int> и есть shared_ptr<const int>. Это разные типы.

Так что смысл вашего примера все еще не ясен.

Так вопрос и был риторическим. То есть, весь блок будет валиться с плохо отслеживаемой причиной.

Вы, видимо, о C++ наслышаны лишь поверхностно, поэтому вам кажется, что вопрос выглядит риторическим.

В некоторых местах в C++ можно получить исключение из-за действий, выполняемых самой языковой или библиотечной фичей. Например, при оборачивании лямбды в std::function или при создании новой короутины можно поймать bad_alloc и это вообще никак не будет связано с кодом, который пишет пользователь.

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

По моей ссылке

Есть конкретный пропозал по добавлению паттерн-матчинга в C++. На данный момент третья редакция: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1371r3.pdf

Но масштабируется по уровням абстракций это дело отвратительно.

Опять бездоказательные эмоции? Пример можно?

Любая относительно глобальная ячейка variant с непримитивным значением рано или поздно приходит к этому состоянию.

Бла-бла-бла. Хватит уже говно из вашей башки изливать. Есть конкретный пример? Если есть, то показывайте.

То есть, исключения обработаны, локальные ресурсы корректно высвобождены, но исключение было брошено при изменении variant

То что?

Если ваш код обеспечивает базовую гарантию, то экземпляр variant, который был поврежден при выбросе исключений подлежит либо уничтожению, либо должен получить новое значение. Точка.

Любое другое использование проблемного variant – это алгоритмическая ошибка программиста. А раз она допущена, то нет смысла рассматривать случаи, когда variant пошел в паттерн-матчинг и там не обработали ситуацию с отсутствием значения.

Если же в вашем коде строгая гарантия или nothrow-гарантия, то у вас не будет проблемного экземпляра variant.

Любой идентификатор для определения типа значения в tagged union.

Тогда мы возвращаемся к тому, о чем я вам уже говорил: в случае std::variant (или любого его аналога) вы в compile-time имеете список типов и какой-то «неожиданный» элемент в этом списке у вас появится не может.

Предлагаю сравнить с C#

От графомана с проблемами в логических цепочках подобного сравнения и стоило ожидать. Тут у нас как бы C++, нативный язык, где во главу угла ставится zero cost. А вы ему пытаетесь противопоставить язык со сборкой мусора, с неконтролируемыми программистом расходами на создание экземпляров reference types и т.д.

Так это один и тот же int!

Я там не вижу одного и того же int-а. Есть shared_ptr и есть shared_ptr. Это разные типы.

Так что смысл вашего примера все еще не ясен.