Встреча ISO C++ в Софии: С++26 и рефлексия

Ну, насколько я понимаю, разница в именовании проистекает из принципа работы. template for - это именно шаблон, по которому компилятор перегенерирует "тело цикла" для каждого элемента из указанного списка. А if constexpr сам по себе никакой генерацией кода не занимается, компилятор просто выбирает один из вариантов в соответствии со значением constexpr условия. По-моему достаточно логично.

Встреча ISO C++ в Софии: С++26 и рефлексия

Да вроде нормально взаимодействует. Как и с return внутри себя.

Встреча ISO C++ в Софии: С++26 и рефлексия

и перенес её действие до цикла

Вообще-то нет.

это даёт последовательность и уже пройтись по последовательности так звучит ожидаемо и очевидно

У вас не делается ничего подобного. Вставьте отладочную печать скажем в лямбду и непосредственно перед строкой с for и убедитесь.

Почему C++ считает мой класс копируемым, если его нельзя скопировать?

Шаблоны тут вовсе не при чем. В C и C++ широко практикуется отделение объявления от реализации, и is_copy_constructible далеко не всегда может проверить, что именно делает copy constructor. Вот например без всяких шаблонов:

$ cat module.h
struct Base
{
    Base() = default;
    Base(Base const &) = delete;
};

struct Derived: public Base
{
    Derived() = default;
    Derived(Derived const&);
};

$ cat module.cpp
#include "module.h"

Derived::Derived(Derived const&) : Base() {}

$ cat main.cpp
#include <type_traits>
#include "module.h"

static_assert(std::is_copy_constructible_v<Derived>);

int main() {}

Как прикажете is_copy_constructible в main.cpp проверять, что именно делает конструктор копии, реализация которого находится в module.cpp? Что, если module.cpp существует только в виде какого-нибудь module.so?

Релиз Rust Coreutils 0.1.0

Это здесь не при чем.

Это здесь при всем. Все ваши претензии по сути к этому и сводятся - мол, "неудобно" брать код под GPL, включать его в свой закрытый продукт и не делиться с сообществом. This is by design.

Опенсорс давно перешел

Если бы не GPL, никакого "опенсорса" в текущем его виде вовсе не было бы. Был бы только закрытый софт, облепленный EULA, как говно - мухами. Вы либо плоховато помните обстоятельства, при которых вообще появились GNU и FSF, либо просто не застали их в силу возраста.

Релиз Rust Coreutils 0.1.0

Теоретически можно, а практически наверняка заглядывали.

Релиз Rust Coreutils 0.1.0

переписать все с gpl на mit?

Ну тут кстати есть интересный момент. Сильно сомневаюсь, что разработчики coreutils на расте ну прямо никогда-никогда не заглядывали в исходники соответствующих GNU Coreutils, хехе.

Создание объектов без конструктора по умолчанию в C++: искусство владения памятью

Буханка-троллейбус.жпг

Open Source и C++: делай что должен и свершится, чему суждено

Нет, зачем компилятор с/с++? Go достаточно.

Ну как же, вот я например хочу использовать в своем приложении sdl2 (или любую другую библиотеку, написанную на C) через например вот такой враппер. Враппер при наличии только go вы может и соберете, а саму sdl2 кто будет собирать?

На понятно что gui приложение ты не соберёшь так, но это другое ограничение другого языка уже.

Таким образом можно собрать только относительно несложное приложение без зависимостей написанных на других языках. А другие языки были, есть и будут есть, потому что серебряных пуль не существует.

Open Source и C++: делай что должен и свершится, чему суждено

То есть можешь поставить в системе go

Ну собственно на этом можно и закончить :) Шутка (наполовину). А если серьезно - мы же берем случай не хелловорлда, а серьезного приложения с зависимостями, написанными на разных языках. То есть возвращаемся к началу - для "решения проблемы" (человек хочет попробовать новое приложение) ему нужно поставить go, поставить C/C++ компилятор, возможно, растокомпилятор (для зависимостей)... Боюсь, что с таким подходом у вас не получится значительно расширить пользовательскую аудиторию :)

Open Source и C++: делай что должен и свершится, чему суждено

в то время как в других языках эта проблема решена

Это в какой-то степени решено только в языках, которые имеют свой рантайм (типа упоминавшихся вами питона, явы или шарпика), там просто все эти проблемы переложены на рантайм - и опять же, только если у вас нет вызовов каких-то сторонних библиотек через native interface. Говорить же, что эта проблема решена в языке потому что он может статически слинковать бинарь - ну, ИМХО, такое. И опять же, этот статически слинкованный вами бинарь, даже если нет никаких условных плагинов (или вы их не забыли все трудолюбиво найти и добавить в пакет), все равно будет точно так же огребать в винде или макоси от паранойи с подписями, как у вас в статье написано.

Open Source и C++: делай что должен и свершится, чему суждено

Это только в теории так все просто, со сферическим конем в вакууме. На практике же например у используемых вами (возможно, даже не напрямую) библиотек бывают плагины, которые статически просто не линкуются, а подгружаются исключительно динамически (через dlopen() или подобные механизмы). Более того, на разных системах нужны разные плагины в зависимости от... много чего - например, где-то нужен плагин для Xorg протокола, а где-то для Wayland, версия библиотеки, установленная в системе, об этом в курсе, а то, что вы там статически себе прилинковали - нет. Го вам поможет только в наипростейшем случае хелловорлда, что-то чуть более сложное - и вы будете совершенно так же огребать.

Open Source и C++: делай что должен и свершится, чему суждено

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

Open Source и C++: делай что должен и свершится, чему суждено

Везде наличие компилятора/интерпретатора языка даёт гарантию подключения зависимостей.

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

Open Source и C++: делай что должен и свершится, чему суждено

Честно говоря, я не очень понял претензии к языку. Установка неподписанных/ненотаризованных бинарей - это в любом случае проблемное дело в той же винде или в macOS вне зависимости от того, на каком языке написано то, из чего эти бинари собраны. А если вы хотите просто показать потенциальному пользователю свое приложение в режиме "скачать и запустить", то требовать, чтобы этот потенциальный пользователь имел тулчейн для его сборки (а скорее всего еще и тулчейны для сборки всех его зависимостей, ведь они могут быть написаны на разных языках), каким бы распрекрасным и удобным этот тулчейн ни был - ну, такое.

Как Мэтт Годболт «продал» мне Rust (рассказав о C++)

Вот мне кажется, что текущие компиляторы для х86/х64 кинут литерал в сегмент данных и ссылка никогда не пропадёт. Но это стандартом для всех систем и оптимизаторов! не гарантируется.

Вообще-то гарантируется: строковые литералы гарантированно имеют static storage duration:

Evaluating a string literal results in a string literal object with static storage duration.

Как Мэтт Годболт «продал» мне Rust (рассказав о C++)

Точно не могу сказать :)

Как Мэтт Годболт «продал» мне Rust (рассказав о C++)

Ну то есть в своих широковещательных заявлениях основываетесь не на какой-то статистике, а на собственных каких-то представлениях "из головы" и собственном опыте. Тогда стоит добавлять к своим заявлениям "ИМХО", а не преподносить их как факт. Не ведите себя как растофанатик, ведите себя как инженер.

какое-то C++ сектантство в духе конторы на букву "я", вынуждающее вас оставлять агрессивные комментарии и прибегать к демагогическим приемам

Здорово, здорово. Нечем подкрепить свои утверждения - обвини собеседника в сектантстве и демагогических приемах. С вами я на обозримое будущее разговор закончил.

Как Мэтт Годболт «продал» мне Rust (рассказав о C++)

Вас не смущает, что почти все программисты на Rust это и есть бывшие программисты на C++?

Я вот заметил, что вы очень любите делать широковещательные и ничем не подкрепленные заявления. Откуда дровишки что "почти все программисты на Rust это и есть бывшие программисты на C++"? Где можно ознакомиться с соответствующей статистикой?

Как Мэтт Годболт «продал» мне Rust (рассказав о C++)

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