apolukhin
commented
3 years ago yndx-antoshkka, 10 сентября 2018, 11:43 Есть схожие предложения:
-
282
-
163
Старый код никто ломать не позволит, так что изменить существующее поведение constexpr функций - невозможно.
Идея с constexpr { любой код } заманчива, но там возникают неожиданные проблемы. Многие хотят, чтобы constexpr блоки, считающиеся на этапе компиляции, выдавали одинаковые результаты на всех компиляторах. Этого не будет, если в таком блоке есть неопределённое поведение. "Интерпретатор" constexpr блоков должен проверять на неопределённое поведение. Для этого он должен видеть тела constexpr функций, иметь полную информацию о коде. Даже обычный new создаёт проблемы: возникает необходимость отслеживать выделенную память и типы данные, созданные в ней. Увы, это крайне нетривальная задача.
Хочется надеяться, что в скором времени получится внедрить ваше предложение в C++. Но сделать это одним махом не получится, и приходится двигаться малыми шажками, постепенной добавляя возможностей constexpr "интерпретатору", убирая ограничения и проч. Надеюсь, что в ближайшие 6 лет получится начать заниматься вашей идеей, но шансы успеть к C++29 не очень высоки.
Fihtangolz, 10 сентября 2018, 14:22 yndx-antoshkka, проблемы нет, нам достаточно ввести ключ компилятора, можно ввести семвер, ночную сборку или еще что то. Не думаю что мы сильно пострадаем от введения constexpr call, constexpr declaration просто перестанут юзать за ненадобностью и его будет не проблема выкинуть. Можно же ввести такую практику, объявляем что фитча выпиливается и ждем год-два и выпиливаем. Где можно посмотреть проблемы? Если честно я их особо не вижу, мне непонятно требование к отсутствию UB - это потребует серьезной переработки языка и по сути, мы изобретем новый синтаксис компаилтайм с++ полностью безопасный. Ну в принципе и это не проблема. Была плохая идея, наверное лучше использовать llvm ir. Дак отсюда и будет следовать отсутсвие UB (как мне кажется) - ub это по сути поведение не определенно но так как у нас llvm и он един для всех машин, то все будет определенно и достаточно поставить затычки на сисколы и тд. Я слаб в этом, не могли бы вы составить еще список проблем исключая UB. Я думаю я могу попро
yndx-antoshkka, 10 сентября 2018, 15:28
std::mutex http://eel.is/c++draft/thread.mutex.class и std::unique_ptr http://eel.is/c++draft/unique.ptr#single.ctor тоже прадлагаете перестать использовать за ненадобностью? У них constexpr конструкторы
Fihtangolz, 10 сентября 2018, 18:19 yndx-antoshkka, боюсь вы не совсем понимаете что я предлагаю, я говорю, что семантический смысл constexpr при добавлении constexpr блока будет нарушен. Constexpr with defenition может выполнится а может не выполнится, зачем вообще такие гарантии? Разве компилятор до этого сам не мог редуцировать? Я говорю что мы хотим использовать constexpr именно при вызове int main() { constexpr add(1,2); return 0; } с жетской гарантией выполнения callable в compile time. Объявление constexpr для defenition можно оставить - оно само отомрет за ненадобностью. Тогда мы вернем нормальнй сематический смысл constexpr. Мне все же интересно какие именно препятсвия мы имеем для переноса constexpr в llvm ir. Если это кросплатформенная байткод машина. Мы можем использовать реализацию дефакто как это делает obj-c. Все UB в рамках это байткода будут четко определенны и соотвественно на всех компьютерах compile time код работающий в баткоде будет детерминирован.
Перенос предложения: голоса +0, -1 Автор идеи: Fihtangolz
Изменить declaretion constexpr на constexpr call
Вообщем на данный момент constexpr видится мне чем то не совсем внятным. Он "попытается" выполнить функцию во время compile time, следом подтянется pure_constexpr или constexpr! боже прости. Но это обсолютно не то чего мы все хотим - а мы хотим generic execution. Соотвественно constexpr должен быть модификатором "вызова/исполнения".
И должен всегда выполнять callable во время компиляции. Дальше больше, если бы заходим добавить модификатор к блоку
то в текушем виде получится снова что то невнятное, тоесть func могут или так или так а блок всегда компаил тайм???
Вообщем надо убивать. + мне лично видится что compile time должен быть настоящим, тоесть без попыток ввести compile time allocation. Бог простит, можно вынести все использования в грал к примеру и тогда у нас будет возможен и std cout, map и тд
P.S. возможно я не прав, прокоментируйте почем. И добавте на сайте после опубликовать не плашку внизу а поп ап для авторизации