Нескучное программирование. Ограничения

[Adequateeee]

Не плохо, мне зашло

[Woodroof]

Либо через SFINAE, те же решения — вид сбоку

А в чём отличие? Полностью идентичный код.

[dalerank]

Спасибо, поправил

[AbitLogic]

"Здесь мы явно говорим, — эта функция существует только для тех типов T, которые удовлетворяют концепту std::equality_comparable, и если попытаться вызвать её с типом, у которого нет оператора ==, компилятор не будет пытаться «протащить» нас внутрь шаблона, а сразу сообщит: ограничение не выполнено — данный тип не является сравнимым на равенство."

Очевидно какая-то попытка получить аналог трейтов из Rust, аля PartialEq, только в отсутствие сильной типизации на уровне компилятора прикрутить типы для типов выглядит как костыль

[dalerank]

Тут просто важно напомнить, откуда всё это взялось. Плюсы все же очень старый язык (40+?) и он десятилетиями развивался так, чтобы ничего не ломать из уже написанного кода, ну и он тоже из ниоткруда не появился, а взял часть сях, часть smalltalk, tcl и чего там еще было в начале, поэтому он не может просто взять и «переделать систему типов заново», вы банально все сломаете и даже ваша кошка будет смотреть на вас осуждающе. Поэтому все новые штуки, вроде концептов concepts, приходится аккуратно надстраивать поверх старых шаблонов, SFINAE и прочего исторического багажа и ничего с этим не поделать. Может из-за этого они иногда выглядят как костыли, хотя по сути это эволюция.

Rust оказался, кмк, в куда более удобной позиции, поскольку стартовал с чистого листа. Можно было сразу сказать: вот у нас traits, вот тут такие правила, вот вам такая строгая модель типов и никаких компромиссов ради кода, написанного дцать а то и больше лет назад, поэтому всё выглядит «правильно».

При этом rust на самом деле очень много взял из C++, тотже RAII, zero-cost abstractions, общее мышление про производительность, но он смог взять эти идеи уже в отшлифованном виде и встроить их в язык сразу, а не задним числом и не через три п.... извините за мой французский.

Так что концепты в плюсах это не попытка догнать rust, а попытка как-то наконец-то официально оформить то, чем люди пользовались годами, если не десятилетиями, через enable_if, type traits и прочие трюки. Ну да, выглядит менее элегантно, но работает и не ломает экосистему.

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

[AbitLogic]

В принципе у Вас здоровое мнение, ничего плохого не вижу, проблемой плюсов тоже считаю легаси, но взгляните на Си, они хоть и имеют легаси куда большую, я бы предпочтитал писать на них - потому что не метались за совершенное, я открываю С++ теряюсь в их glvalue, xvalue, prvalue, одна move-семантика чего стоит, у вас на руках была нормальная move-семантика, нет нужно изобретать свою, лишь бы работало старое, дальше initialization list, что это? В каких скобках {} или () какой из убойного набора конструкторов вызовется, ну честно, какие-то гикки до хрипоты спорят... Как на этом писать, в Rust невозможны вопросы "что выведет эта программа", там все инструкции явные, сильная, статическая, строгая типизация, никаких неявных преобразований, что написано то и будет

[Mingun]

ничего с этим не поделать

Поделать просто -- не пытаться компилировать все юниты компиляции в одной модели, а разделить -- это компилируем по старым правилам, а это по новым. Уровень оптимизации ведь для разных файлов по разному настраивать можно? Почему нельзя настроить и остальное? Просто удивительно, что все вокруг это уже поняли, и только Комитет упорно пытается впихнуть невпихуемое из года в год. Худо-бедно у него это получается, но все больше разработчиков вопрошает, что там курят.

[dalerank]

Вы не один это видите - это понимают вообще все, в том числе и комитет (я както говорил на конференции с @antoshkka об этом, там работают очень умные люди, которые прекрасно видят и технический долг и архитектурные проблемы языка) Радикальный разрыв тут просто невозможен, пока язык реально используется в проде, и именно поэтому вместо красивого перезапуска мы видим concepts, modules и constraints, в виде медленных шажков. Разбивка по файлам, о которой Вы сказали и TU это чисто про генерацию кода, а не про семантику языка (name lookup, overload resolution, правила шаблонов, ADL, ODR, ABI) должно быть одинаковым во всей программе, иначе компоновка будет давать разные результаты при каждой перекомпиляции (это один из моментов), если ввести разные модели языка, условно старую и новую, то у нас отваливается ODR (тут вам больше ребята с конференций расскажут). И вы забываете про вендоров, если ктото из большой тройки говорит - нет, мы не можем это сделать, комитет под козырек и откладывает на следующий стандарт.

[Jijiki]

на самом деле не поделать, потомучто, обратная совместимость, Раст пользуется миром с/с++, я по началу тоже думал всё просто, поэтому ввели концепты, но модели исполнения кода совершенно разные, образно у нас есть Форт на стероидах, и прямое исполнение

проблема если учесть нового игрока Раст звучит теперь так, надо изменить неизменяемое, из-за модели исполнения Раста, это практически невозможно

Раст кстати проще С++, из-за доказательств перед исполнением, Раст практически функционален как мне кажется, тут не совсем даже синглтон как в С++, оно вроде похоже на синглтон из мира С++, но тут нормально так сделали, что даже не чувствуется тех проблем ), тем кому не нравятся синглтоны и зависимые структуры данных, даже не знаю, как в стиле ООП писать на Раст

потестил Раст всё в одной структурке компактно новейший Opengl, новейшие воксели )

но кстати если забить на Раст и подумать о Хаскель, то многое пофиксили поидее уже давно, правда я не смотрел как там пишут библиотеки, тоже наверно бинды, над низкоуровневыми интерфейсами

да и редактор Zed, оказался вообще клёвым ), такими темпами Раст действительно становится удобным инструментом, семантика мув тут просто классно работает