Это оттуда вон сверху

Короче написанное выглядит оче странно, в частности, forward всегда имеет шаблонные параметры

Короче написанное выглядит оче странно, в частности, forward всегда имеет шаблонные параметры

Это псевдокод

Это псевдокод

А почему не decltype(auto)

А нет там все нормально

тогда можно вот так std::vector v = {1, 2, 3, 4} final;

Гыг

Lol

Ну не знаю, сначала вроде получи future, потом толкай promise в асинхрон.

Ну не знаю, сначала вроде получи future, потом толкай promise в асинхрон.

Да я согласен

Я просто не увидел

Слишком много шеред поинтеров

в си безотносительно к архитектуре считается, что необъявленная функция возвращает инт? т.е. даже на х64?

безотносительно. Но никто не гарантирует одну и ту же длину int-а на разных архитектурах

спс

foo bar; if(bla) { undefine bar; } foo /// wtf???

Так, теперь я не понял вопрос

Так, теперь я не понял вопрос

фигня ваш undefine — сыпется в условных ветках

фигня ваш undefine — сыпется в условных ветках

Возможно он должен уничтожать для текущего скоупа. Тогда внутри тела (возможно большого) можно запретить использовать что-то внешнее. Как тебе такой вариант

foo bar; if(bla) { bar = delete; // lot of code bar.call(); // 'bar' is undeclared in this scope } bar.call(); // ok

Возможно он должен уничтожать для текущего скоупа. Тогда внутри тела (возможно большого) можно запретить использовать что-то внешнее. Как тебе такой вариант

Он полагает копирование всего стека при входе в скоп?

Уничтожать неправильный термин я подобрал

"отвязывать" или данном случае "запрещать" использовать переменную в этом скоупе

Но самое печальное в усложнении размотки стека. Мало джампнуть в нужную точку для вызова деструкторов. Каждый становится условным

Ты сейчас со мной говоришь? Это компайл тайм проверки

Ну если borrow в условной ветке

Ну если borrow в условной ветке

Покажи пример)

If(condition) rlymove(obj);

If(condition) rlymove(obj);

Понял if (condition) move(obj); obj = delete;

Согласен. Не получится. Либо придётся писать два раза

Хотя с другой стороны если объект внутре movable он всё равно там содержит какой то чек. Может стоимость и оправдана.

Только вот ви донт пэй. Потому не руст.

Только вот ви донт пэй. Потому не руст.

Э?

фигня ваш undefine — сыпется в условных ветках

не знаю, что там у кого сыпется)

не знаю, что там у кого сыпется)

самое главный вопрос, нахер ж так писать

самое главный вопрос, нахер ж так писать

ну у меня лично горит от отсутствия __finally_use(name)

ну у меня лично горит от отсутствия __finally_use(name)

че за зверь

ну у меня лично горит от отсутствия __finally_use(name)

ну а для кого скоупы придумали?

че за зверь

undefine-ит переменную и возвращает её значение

не влияет на порядок удаление, только синтаксическая проверка, кроме move

undefine-ит переменную и возвращает её значение

пытаюсь понять когда это нужно и не понимаю

пытаюсь понять когда это нужно и не понимаю

когда у тебя форвардит функция параметры

Э?

Ну там чот есть же наверное уводящее вообще переменную из scope, threads или типа того.

Ребят решение ещё из Си есть. Но как верно сказал Дмитрий, пока новое НЕ придумаешь

пытаюсь понять когда это нужно и не понимаю

когда у тебя временная переменная одноразовая возникает в явном виде, потому что иначе слишком много букв в одном операторе

когда у тебя временная переменная одноразовая возникает в явном виде, потому что иначе слишком много букв в одном операторе

и когда много букв стало проблемой?

и когда много букв стало проблемой?

когда оператор на вложенность 30 улетает - проблема

когда оператор на вложенность 30 улетает - проблема

э?

когда оператор на вложенность 30 улетает - проблема

hadouken_if.jpg?

Покажи, как бы ты хотел

ну у меня лично горит от отсутствия __finally_use(name)

Просто смотри какая проблема

__finally_move() я бы хотел

for(int i = 0; i < 3; ++i) { if (i % 2) { bar = delete; } bar.call(); }

или просто __finally_use если там понятно

for(int i = 0; i < 3; ++i) { if (i % 2) { bar = delete; } bar.call(); }

CE

или просто __finally_use если там понятно

Пример выше

if (false) bar = delete; bar.something(); //CE

Вместо = delete поставь finally use

аналогично

if (false) bar = delete; bar.something(); //CE

Да уж, придется для компилятора писать такие проверки.

при ветвлениях условие на выходе типа "или", любая ветка убивает => убито

А какая губина убийство

Член класса можно убить?

нет

А статическую переменную захваченную лямбдой?

Много проблем

?

захваченная лямбдой переменная это член класса

вот при захвате можно убить

террористы, все бы вам убить, удалить и поделить на 0

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

Много проблем. Я как бы днём был за, теперь против

я не знаю проблем

я не знаю проблем

Не не, если компилятор будет находить ошибки компиляции по типу тех, что в моем примере кода, то ок. Я просто думаю, что его можно упороть

я не знаю, как можно упороть формальные правила

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

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

Я просто как бы предлагал ещё shadowing float l = 2.3; override list<int> l = { 2, 1, 1, 6 };

Я просто как бы предлагал ещё shadowing float l = 2.3; override list<int> l = { 2, 1, 1, 6 };

Вот это точно в печь

Вот это точно в печь

Почему

Потому что это лишний способ ошибиться

И не больше

Я просто как бы предлагал ещё shadowing float l = 2.3; override list<int> l = { 2, 1, 1, 6 };

чо?

Потому что это лишний способ ошибиться

Компилятор не даст

Не понимаю, зачем одинаковым именем называть две сущности

Не понимаю, зачем одинаковым именем называть две сущности

Я приводил пример

Я приводил пример

Давай еще раз, не верю в его существование

Бля, админы потерли всё нахер

Сейчас заново напишу

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

Но до этого точно дальше, чем до Парижа

стало uint userId = toUInt(json["id"]);

все счастливы

зачем

конвенция: не создавайте одноразовые переменные

снова с этим бредом лезешь?

зачем

Для сериализации/десерализации удобно

плюсую, это бред

Для сериализации/десерализации удобно

не оч