[prog.c++.idiotic] Позволю себе еще раз пнуть deducing this, который вводят в C++23

В C++23 давно добавили такую фичу, как deducing this. К которой лично я отношусь очень негативно. Как по мне, так с deducing this язык C++23 еще больше повышает планку требований к разработчикам. И сейчас С++ на должном уровне освоить могут не только лишь все, а уж хорошее знание и умение вменяемо использовать C++23 будет доступно, полагаю, только надмозгам.

На тему deducing this я уже несколько раз в разных соцсетях негативно высказывался. Более того, когда-то в Habr-е в комментариях даже набросал пример того, как часть задач deducing this можно было бы решить и "в традиционном" C++ном синтаксисе, не превращая C++ в подобие Python-а и Rust-а с явной передачей self-а в нестатические методы:

class params {   int limit_;   ... public:   // Иммутабельный геттер.   [[nodiscard]] int limit() const &, const && noexcept {     return limit_;   }   // Мутабельный сеттер. Может использоваться если params   // применяется в стиле builder pattern.   decltype(*this) limit(int v) &, && {     if(v < -10 || v > 40) throw std::invalid_argument{...};     limit_ = v;     return *this;   } };

А вот давеча прочитал статью от Сандора Дарго "C++23: some changes related to templates" и узнал, что к deducing this еще и новый std::forward_like прилагается. Мало нам было std::forward и std::move, теперь еще и std::forward_like в придачу :(

PS. Не могу не поделится еще на одну статью с примером применения deducing this: "User-defined class qualifiers in C++23". Отличный пример того как упороться новой фичей и еще один способ превратить код в головоломку.

[prog.flame] Может ли аккуратно написанный код выглядеть и пахнуть как говнокод?

Таки да!

Вот реально, если бы этот фрагмент прилетел бы ко мне на сопровождение, то у меня бы нехило пригорело бы. Уже хотя бы от того, что даже в его оформлении используются элементы, которые меня лично сильно подбешивают. Но там и парочки объективных проблем хватило бы, чтобы я сильно приуныл.

Во-первых, количество аргументов метода search. Тут как в старой программерской мудрости: если ваша функция получает 10 аргументов, то вы наверняка забыли передать туда еще что-то :) Кроме того, есть подряд идущие аргументы одного типа (например, три аргумента типа dim_t, затем три аргумента типа bool). Мой опыт показывает, что это прямой путь к тому, что рано или поздно какое-то из значений будет перепутано.

Во-вторых, объем метода. Ну он просто слишком большой. Вот честно завидую людям, которые в состоянии все происходящее в методе такого объема удержать в памяти. И не просто удержать, а еще и убедится, что там все корректно.

Вот, скажем, мой взгляд зацепился за объявление переменной biased_decoder типа std::unique_ptr<BiasedDecoder>. Она инициализируется реальным значением только при выполнении некоторых условий, в остальных случаях там будет nullptr. Используется же потом этот biased_decoder всего лишь один раз, довольно далеко от того места, в котором он был создан. Где гарантии, что никто к biased_decoder не обратится еще раз, не проверив предварительно bias_towards_prefix?

Или вот этот вот keep_batches, который так же unique_ptr, но который объявляется вне ветки if-а, в которой он затем создается и используется. Нафига, спрашивается? Там же вообще, насколько я понимаю, можно было обойтись без unique_ptr и объявить keep_batches как обычную переменную на стеке прямо в том месте, где она потребовалась...

Конечно, очень смело с моей стороны судить о коде, в котором не разбираешься (а ведь я не в зуб ногой в этой предметной области). Но тут просто профессиональный нюх подсказывает, что этот код хрупок. И нипривидихоспади столкнуться с сопровождением такого кода. Хотя, конечно, доводилось видеть и пострашнее. Но там сразу было видно, что говно-говном. А здесь вроде как все чистенько и аккуратненько, но с запашком, однако :(

Для тех, кому лень переходить по ссылке на github, под катом весь фрагмент, к которому я докопался.

ЗЫ. На этот проект вышел через здесь, захотелось посмотреть, что там в других местах с качеством C++ного кода.