Текущий вариант стандарта выглядит гораздо более вменяемым, чем то, что нам показывали пару лет назад. Вместо фантазий на тему "как нам сделать из шаблонов настоящий пацанский compile-time Haskell" видим решения изрядно подзадолбавших проблем и некоторое количество легко имплементируемых и вполне приятных (хотя и совершенно необязательных) бантиков.
Что я точно буду использовать с огромной радостью в повседневном кодировании:
(всё это без комментариев; если вы не понимаете, с чего бы такой восторг, то вы вряд ли действующий программист на С++, ну в смысле, такой, который на нем не только в CotPedro участвует, или как там этот конкурс называется, а по эн часов в день какую-нибудь функциональность пишет)
Бантики, которые мне нравятся:
- enum classes (строгая типизация и долгожданная возможность forward declaration для enum'ов)
- constexpr (приятно быть уверенным в том, что компилятор тебя понял)
- делегирующие конструкторы (без комментариев)
- static_assert - ну, просто приятно, что не нужно будет эту базовую фичу дурным макросошаблоном имитировать
- nullptr - теперь нельзя будет перепутать и передать нулевой указатель туда, где ожидается int, char, float или bool (особенно частое явление при вызове функций с параметрами по умолчанию, из-за этого мы в московском Вогстере "умолчания" вообще запретили себе использовать)
- raw string literals, и, конечно, юникодные строки (без комментариев)
- user-defined literals (красивые, но находятся где-то почти на грани бесполезности)
- thread-local storage как встроенная фича языка (простановкой одного слова рядом с нужными глобальными и статическими переменными можно превратить значительную часть legacy потоко-небезопасного кода в безопасный)
- std::array (старый добрый fixed_vector, неужели я больше ни разу не напишу тебя вручную?)
Фишки для метапрограммирования, которые мне нравятся (да, и такие есть!):
- decltype
- variadic templates (конечно, редко когда требуется, но уж если потребовалось... в общем, прощайте, безумные александресковские typelist'ы)
Чего я не жду и, скорее всего, особенно использовать не стану:
- <ересь>лямбды
- std::initializer_list, {}-инициализация (разве что для in-class member initializers)
- suffix return type syntax (умопомрачительный бред, надеюсь, они все-таки поменяют этот синтаксис на auto)
- template alias (хоть что-то похожее на возможность его осмысленно использовать я смутно припоминаю раза два за свои 10 лет программирования на плюсах)
- rvalue-references (в подавляющем большинстве случаев swap'а и/или передачи указателя достаточно; там, где это не так, я хотел бы, чтобы "копирующее" решение синтаксически сильно отличалось от "перемещающего" - не хочется пропускать случайно или злонамеренно написанное первое)
- extern templates (человек должен писать лишнее, чтобы помочь линкеру и компилятору? вы там не охренели?)
- версионирование при помощи inline templates (в мире очень много мертворожденных концепций якобы "автоматического" версионирования; вы вообще видели хоть одну, свободную от аналогов dll hell?)
- всякие очередные смартпоинтеры в STL (можно подумать, их и без того мало)
Непонятности:
- Треды и примитивы синхронизации в STL. Будет ли это пригодно к использованию, и как это будет сочетаться с legacy кодом - бог весть.
- regex'ы, random etc - туда же
- Странная концепция атрибутов, странный синтаксис, странный набор "стандартных" атрибутов (хотите заменить прагмы и declspec - ну так обеспечьте синонимы хотя бы для самых распространенных, хотите compile-time проверку ошибок - добавьте хотя бы override)
- КАКОГО ХРЕНА ОНИ ТАК И НЕ ПУСТИЛИ В ЯЗЫК VARIABLE SIZE ARRAYS? Оно же в нормальных компиляторах уже сейчас работает? Чем им не угодила возможность писать int array[n] вместо int* array = (int*) alloca(n * sizeof(int))? Что Страуструп под этим своим "thank heaven for small mercies" подразумевает?
- Назвали hash_map unordered_map'ом. Очень мило. В namespace положить нельзя было никак?
Очень, очень жаль, что они так и не догадались сделать implicit variadic templates, итерация в которых происходит по всем параметрам заданной функции или по всем видимым членам заданного класса. А получилось бы красивое и унифицированное решение проблемы сериализации, "далеких вызовов" a la com/corba и т.п.
В общем, надо бы еще <ересь>отпилить лямбды, и можно стандарт выпускать.
Вы-то сами на этот счет что думаете?