Georgy Firsov

> Instead of CLion-based code style checking we need to provide a clang-tidy config that defined code style. So this PR should be linked to #25 too. To be implemented...

Во-первых, это попросту использование обобщенного синтаксиса: ```cpp const auto [var = GetAwesomeValue()] { /* ... */ } ``` Во-вторых, в таком случае теряется некоторая смысловая нагрузка: при захвате по lvalue-ссылке...

> вы тут явно видите std::move? ```cpp std::vector obj1 = ..., obj2 = ...; const auto foo = [](auto &&) { /* ... */ }; foo(std::move(obj1)); // Вот тут прекрасно...

> так речь идёт об упрощении данного синтаксиса, что бы не писать длинный std:move... Ну а я привожу аргументы против такого "упрощения". Кроме того, это не упрощение синтаксиса, а введение...

> А где граница между упрощение синтаксиса и введение нового? Вот CTAD, например, это упрощение: ```cpp std::vector v1 = { 1, 2, 3, 4 }; std::vector v2 = { 1,...

Это имеет смысл возможно только при наличии каких-либо других аргументов, помимо указанного пака параметров, хотя и тут выкрутиться можно. Что же касается случая, приведенного выше, то оно, начиная с C++17...

`rbegin` же есть для подобного. Да и сделать из него обычный итератор, поколдовав с методом `base`, проблем не составит

> А как таковой имплементировать в `forward_list` без итерации по всем элементам, если у него указатели направлены в одну сторону? Я проглядел часть про `forward_list` :) Ну тут как бы...

Немного неясны несколько моментов: - Почему `trim[_if]` должны возвращать `size_type`? Логичнее возвращать ссылку на себя, как в моем оригинальном предложении. - Зачем передавать вариадик-пак чаров? Есть уже замечательные функции ```cpp...

> Делал по аналогии с erase[_if]: функция возвращает количество удаленных элементов Есть нюанс. Тот же `erase` не предполагает использования её результата прямо на месте, а вот `trim` выглядит очень органично...