Ivan Sokolov
Время пятничного зачилла пришло с запозданием и не в тот паблик.
Надеюсь, все уже знакомы с P2806 do expressions. Я бумагу пока даже не открывал. Поговорим про очевидный прародитель и этого предложения, и похожих конструкций в разных языках. Statement expressions в GNU C позволяют писать compound statement там, где нужен expression. В случае C на этом их описание практически заканчивается.
Итак, тип и значение полученного выражения берётся из последнего statement внутри скобок, если это выражение...
int x = ({
int sum = 0;
for(int i = 1; i <= 10; ++i)
sum += i;
sum;
});
// x = 55
...причём вывод типа похож на ->auto, и на это не повлиять.
int i = 0, &ri = i;
// decltype(({ ri; })) = int
// decltype(({ (int&&)i; })) = int
Guaranteed copy elision работает, но аналога RVO нет.
struct immobile { immobile(); immobile(immobile&&)=delete; };
struct moveonly { moveonly(); moveonly(moveonly&&)=default; };
auto x = ({ immobile(); }); // ok since C++17
auto y = ({ moveonly m; m; }); // error: call to deleted copy ctor
Но то всё мелочи. Сабж выгодно отличается от замыканий возможностью control flow, влияющего на содержащую функцию:
while(1)
while(({ break; // gcc: breaks outer loop
// clang: breaks inner loop
1; }));
goto внутрь делать нельзя, но можно наружу, в том числе вниз:
auto v = ({
goto out;
std::vector<int>();
});
out:
// The usual error "jump crosses initialization of v"
// does NOT happen. v is uninitialized.
// Its destructor will probably crash.
...Если вы ещё не забыли, у нас тот самый пятничный зачилл. Есть малозначительные разногласия по поводу того, где сабж в принципе разрешён.
int i = ({1;}); // error: never ok outside functions
decltype(({1;})) i; // error: ...even in unevaluated context
struct foo {
decltype(({1;})) i;
// error: again, never ok outside functions.
// gcc emits disappointing but correct message
// clang complains about file scope even though it's not
};
int main() {
std::integral_constant<int,
({ 1; }) // gcc: error
// clang: ok (as long as inside function)
>{};
}
Чтобы не думалось, что clang нам сегодня компилирует строго больше кода:
constexpr int i = ({ int j = 0; j; });
// gcc: ok
// clang: error (j is not a constant expression)
В комметарии приглашаются мнения по поводу того, кто в каком случае прав и если никто, то как надо. Ссылки на стандарт будут всячески порицаться и осмеиваться.
(Тем временем надеемся, что комитетские ЛОМы и ЛПРы, вдохновившись этой хорошей фичей, подумают покрепче и сделают в итоге отличную. Ну или не надеемся)
5 · 839 ·