Предложения
Сортировать
-1
-2
The main, semantically lacking, boilerplate in the usage of the `std::move` today is for the sinking of variables that we no longer need, especially locally. It's not like the `std::move` for a transfer of ownership, but a suggestion to make an optimized copy. This proposal is similar in spirit to the current behavior of return statements, which are effectively xvalue expressions in cases when they can't be elided if an automatic storage duration variable is returned.
0
-1

Сейчас преобразование целого в указатель делается через reinterpret_cast, который запрещен в constexpr выражениях. Но если мне известен адрес на этапе компиляции, то почему я не могу привести его к типу указатель? Можно ввести, что типа pointer_cast для выполнения этой операции.

C++20
0
-4
Расширить name lookup, чтобы вызовы вида "classInstance.classMethod(args...); " "искались" не только, как "ClassType::classMethod(args...)", но и как "classMethod(ClassType &, args...)".
12
-3
Сейчас в списках инициализации инициализируемые сущности могут быть записаны в любой последовательности, однако реальный порядок инициализации от этой последовательности никак не зависит, что провоцирует возникновение дефектов в программах.
2
-2
Несоответствие объявленного типа таких параметров фактическому (например в int foo(int action()) параметр action - это указатель) затрудняет работу с ними провоцирует возникновение дефектов в программах.
11
-0
Добавить в стандартную библиотеку функции копирования, сравнения и т.д. для выравненных адресов.
-4
-7
Так как с точки зрения реализации лямбда в C++ представляет собой уникальный класс с определенным в нем оператором (), то потенциально ничто не ограничивает возможность перегрузки этого оператора для различных наборов аргументов