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

Тогда вариант с лямдой

ну по сути то же самое

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

если речь о том, чтобы обязать выполнять нечно перед return, то почему не изменить протокол с приватными функциями и обязать вместо int возвращать ResultCodeSetter

?

а если мне нужен не MoveConstructible параметр из scope, мне вложение строить каждый раз?

каждый выход из функции ОБЯЗАН указать значение

можно сделать возвращаемое значение типа struct Foo, лямбду auto ret = [&](auto res) { err_code = res; return Foo{}; }; и тогда вернуться из функции можно будет только через return ret(-1);

так-то понятно, что я могу написать auto вместо void и сказать auto end_function = [&](int return_code) -> std::integral_constant<int, __LINE__> { /*use everything I want*/ return {}; };

ну вот

Чо нашёл! https://github.com/stlab/libraries

ну вот

а если у меня функция должна не void вернуть, а осмысленное значение?

а если у меня функция должна не void вернуть, а осмысленное значение?

аналогично, но ret_function принимает 2 аргумента

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

а если у меня функция должна не void вернуть, а осмысленное значение?

std::tuple?

std::tuple?

std::tuple<auto, int> в каком стандарте компильнется?

это как вообще, лол

я о том же

чёт ум за разум заходит уже, зачем auto, вроде ж речь шла про то чтобы переписать 👇, не?

void SomeFunction() { if (path1) { exit_code = 1; return; } if (path2) { exit_code = 2; return; } if (path3) { exit_code = 3; return; } }

текущий чит auto SomePublicFunction(); //impl auto end_function = [&](int return_code) -> std::integral_constant<int, __LINE__> { /*use everything I want*/ return {}; }; if (path1) return end_function(1);

только для функции с типом вместо void

и аналогичный чит не сработает, если возврат был не void

шото я совсем перестал понимать

что тут непонятного? мне нужен SCOPE_EXIT, требующий параметр при EXIT

деструктор с параметром меня бы устроил :) (нет)

а параметр будет определён в процессе выполнения функции?

деструктор с параметром меня бы устроил :) (нет)

это алокатор чтоль

а параметр будет определён в процессе выполнения функции?

параметр зависит от ветки возврата, так что да

что тут непонятного? мне нужен SCOPE_EXIT, требующий параметр при EXIT

Непонятно чем плох вариант с функцией или лямбдой. Но чисто гипотетически вопрос любопытный.

Непонятно чем плох вариант с функцией или лямбдой. Но чисто гипотетически вопрос любопытный.

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

локально для функции определить класс с деструктором и параметром, создать объект, начать выполнять ветки, дойти до конца, проинициализировать параметр в объекте и вернуть что нужно?

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

И?..

void func(){ SomeNotMCType object; return_code = [&]() -> int { }(); return_code = object.remap(return_code); }

или в деструкторе тоже нужно завязываться на происходящее в ветках?

ну это немного изврат

выносмозга-ориентированное программирование

вот что-то такое

почему блин плюсам нельзя предоставить формальное доказательство, что данный std::unique_ptr в данной точке будет nullptr и чтобы в этом случае плюсы не синтезировали вызов десктрутора? :(

почему блин плюсам нельзя предоставить формальное доказательство, что данный std::unique_ptr в данной точке будет nullptr и чтобы в этом случае плюсы не синтезировали вызов десктрутора? :(

нужны dependent types

+

нужны dependent types

что это и с чем едят?

что это и с чем едят?

новая наркота

О! Да это же то, о чем я всю жизнь мечтал

что это и с чем едят?

https://en.wikipedia.org/wiki/Curry%E2%80%93Howard_correspondence

https://t.me/haskellru

как раз тут idris обсуждают с зависимыми типами

я не хочу программировать на хаскеле, я хочу определить struct unique_ptr { constexpr bool magic_word not_null() const { return inner != nullptr; } constexpr bool magic_word surely_null() const { return inner == nullptr; } surely_null unique_ptr(nullptr_t) { inner = nullptr; } ~unique_ptr() { delete inner; } ~unique_ptr() surely_null { } }; и потом писать not_null unique_ptr ptr = make_unique();

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

хуже того, есть проблема, что я не могу изменить тип переменной внутри метода

как вообще оно у тебя в блоке nullptr стало?

а... всё ок

не знаю, как у тебя, а у меня /// Destructor, invokes the deleter if the stored pointer is not null. ~unique_ptr() noexcept { auto& __ptr = std::get<0>(_M_t); if (__ptr != nullptr) get_deleter()(__ptr); __ptr = pointer(); }

я примерчик пишу

и я хочу, чтобы { unique_ptr ptr = nullptr; } //deleter не вызван и не инстанцирован

а где он вызывается?

вот так даже

потому что ежу понятно, что в этом месте указатель будет на nullptr

зачем ты пишешь deleter-ы, которые нельзя инстанцировать?)

это информация рантайма

в любой момент я могу написать ptr.reset(new T);

это информация рантайма

В языке C++ есть cv-qualifier. Если дописать в язык C++ еще один такой же user-defined qualifier, ничего не сломается

но пу сути это уже совсем другой интерфейс должен быть, а не то что предоставляет unique_ptr

напиши null_unique_ptr который не будет требовать deletor

напиши null_unique_ptr который не будет требовать deletor

и выяснится, что я не могу модифицировать тип объявленной переменной

ты плюсы путаешь с другим языком, в котором можно модифицировать типы переменных

я ничего не путаю, нет ни одной причины, по которой компилятор не может вычислять аналог user-defined cv-qualifier на этапе компиляции с модификацией фактического типа переменной

но ему по сути надо проследить дальшейшие цепочки, в которых используется этот объект, чтобы убедится в том, что нелегальных вызовов нет, в которых потребуется деструктор

ему нужно будет вычислить фактический qualifier на момент вызова деструктора

после чего выполнить вызов функции точно так же, как производится выбор функции при наличии cv

Просто вам нужен Haskell

мне не нужен хаскель

хаскель ему не поможет

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

какая ложь...

хаскель ему не поможет

Возможно.

какая ложь...

в списке applications на википедии целых 7

опенсорс?

хочу увидеть проект на больше 10М кода на хаскеле

folly только студией собирается? Кто-нибудь пробовал msys2 ?

на х-ле не нужно столько кода писать, бро