Какое это имеет отношение к аппарату который обязан проходить сертификацию и, соотвественно, обязан соотвествовать определённым требованиям?

Ещё если бы вы эту желязяку чисто у себя использовали и к «сетям общего пользования» не подключали — тогда можно было бы, с натяжкой, к этому всему аппелировать…

А вот твой «реализм» сродни со смиренным отношением к огрызочному «что жрите твари что дают и радуйтесь что еще это не запретили вам» и вообще нужно не давить на производителей, а молча жрать кактусы.

Нет, это как раз ваши потуги приводят к такой ситуации. Потому что я, например, принципиально не покупаю телефоны, у которых нельзя разлочить бутлоадер и поставить свою прошивку. И, о чудо — такие телефоны в продаже появляются. Регулярно.

Да, это не желаемый вами ачр и законодательный запрет анлока — но это лучше, чем залоченное «наглухо» железо.

Вы же, с одной стороны, покупаете «что дают» (вас же никто не заставлял ваш dell venue 7 3730 покупать под дулом пистолета?), а с другой — «исходите на гавно» на форумах (ну или на Хабре вот).

Такая позиция неконструктивна: после того, как производитель от вас деньги получил какие-либо телодвижения ему становится делать банально невыгодно. Что вы там и на каких форумах пишите — его не волнует.

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

Осталось только понять откуда такое право, вдруг, внезапно, появится.

Вот про то, что регуляторы требуют запрета на модификацию радиочасти — слышал. Что корпорации ребуют запретить рут-доступ во всяких этих программах Enterprise Recommended — тоже… а вот право пользователей на такое… не, не в курсе.

Где вы про него услышали-то?

Это называется «быть реалистом»? Тут битва идёт за то, чтобы телефоны с незалоченным бутлоадером (типа того же Google Pixel) в принципе не поставили «вне закона», а вы мечтаете о каком-то там арче и запрете на лок железа.

Понимаете: никто из компаний и правительств не заинтересован в этом. Всех интересует не возможность анлока, а только лишь вопрос «у кого ключи».

Ну и как вы, при такой постановке вопроса, собрались продвигать ваши хотелки?

А не вы вы ли чуть раньше писали про пользователей, которые «с готовностью дают любые разрешения любой установленной приблуде»?

Как это, извините, может сочетаться с «рутом искаропки»?

Для «рута искаропки» есть инжинерные билды. Но их, разумеется, на телефоны, продающиеся в магазинах не ставят и ставить не будут.

И про то, что пустое множество параметров в variadic template допустимо и не требует к себе какого-то особого отношения.

Я где-то утверждал обратное?

Про то, что этот тип вполне себе может сидеть внутри реализации.

Это уже проблемы реализации.

Я же обсуждаю проблемы интерфейса — которые вы напрочь проигнорировали, так как в обоих ваших примерах функции что-то да возвращают и, соотвественно, проблемы пустого списка structured bindings (а по стандарту он пустым-таки быть не может) не возникает.

Ну по вашей ссылке выдвигается классаная теория (e1 and e2 cannot have the same address, but one of them can share withc[0] and the other with c[1]), вот только… ни один компилятор так не умеет.

А единственный недостаток — std::tuple<> занимает не 0 байт.

Это тут вообще причём? RPCAdapter — это не tuple.

Проблема же в возвращаемом значении, но я бы эту проблему решил с помощью какого-нибудь result_wrapper<T> с отдельной перегрузкой для T = void.

Там хоть перегружай, хоть не перегружай — всё равно синтаксис другой.

Разрешили же делать return foo(); в функциях типа void (если foo тоже void возвращает). Вот и для других случаев того же хочется…

Ну да, это тоже проблема, да.

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

Не будет этого никогда — даже у Apple срок поддержки меньше… а им ведь это нужно не чтобы кого-то осчастливить, а чтобы новые позапрошлогодние флагманы народу по дешёвке продать.

Ну будьте же реалистами, в конце-концов!

Это для вас «куча». А разработчики Android округлили до сотен милоионов продаж в год, получили нуль и сказали, что им это не интересно.

Там специфицкий Linux: всё, что можно — вынесено из ядра в отдельные библиотеки и поставляется без исходников.

То, что это получается ещё один случай в кодогенераторе.

Не ручками же это всё пишется.

И да, то, что f(void) — это уже «особый случай» печалит, конечно…

Ссылка на void поможет тем, что не нужно будет в куче мест проверять отдельно — void там или нет.

Грубо говоря хочется, чтобы void был просто как пустая структура. Обычный тип, но без внутреннего содержимого.

Зато автоматическая запись даёт очень много полезного и запрещать её бред и абсурд, т.к. кому надо в любом случае найдут способы, а вот большинству отсутствие такого функционала лишь мешает.

Это может быть абсуром — но это также требование закона в некоторых странах, а держать несколько SKU и бодаться с логистикой многие вендоры не считают нужным.

Не знаю для чего можно использовать void-переменные, но знаю где можно применить void-ссылки.

Например RPC. У нас есть небольшая самописная приблуда, использующаяся примерно так:

auto&& [result, arg1, arg2] = RPCAdapter<int (*)(double, double)>(channel);

Понятно что обычно вместо типа функции там какой-нибудь предопределённый тип.

Так как ссылок на void не бывает, то приходится иметь кучу костылей в реализации — ну и там, где это используется тоже помнить, что для void-функций переменной result нету.

А самое весёлое бывает когда функции — это просто функция. Без аргументов и кода возврата. Тогда получается

auto&& [] = RPCAdapter<void (*)(void)>(channel);

что далеко не всем компиляторам нравится… А clang после этого ещё и начинает заявлять, что, дескать, переменная [] не используется… а как её использовать предполагается, извините?

Было принято решение, что convertibles будут на ChromeOS. Мне оно кажется несколько идиотским (все планшеты на ChromeOS — это же ужас какой-то), но… такова жизнь…

У Гугла досточно принципиальна и жёсткая позиция: война с разработчиками видётся «в открытую». То есть ничего «за спиной приложения» не делается — без крайней необходимости, когда на кону безопасность миллионов пользователей.

В данном случае этого нет так, так что если приложение отказалось от поддержки бэкапа (по умолчанию бэкап как раз включен) — то, стало быть, у него были на то причины…

Меня больше волнует почему потребовалось столько лет чтобы перенести её из Play Games. где она работает уже много лет на самых разных устройствах: запускаете Play Games, оттуда «видеозапись игры», тут же переключатесь куда нужно и пишите видео любого приложения (кроме банковских, включивших режим «особой приватности»). Четыре года назад на Pixel C на Android 7 оно уже точно работало, может и раньше работало…

Я не наблюдал в gcc 7 и 8 с флагом -std=c++17 бòльших проблем, чем при использовании «стабильно» поддерживаемых стандартов.

Рад за вас. Тем не менее это не отменяет того факта, что стандарт C++17 был принят уже после релиза gcc 7.

Он не был частью какого-либо стандарта C++ на момент выхода clang 9, о проблемах в котором вы пишете.

Его статус был ровно таким же, как фичи C++17 в GCC 7. Стандарт ещё не был утверждён в момент выхода GCC 7, извините.

То, что вы не напоролись ни на какие проблемы… ну — повезло вам. Я знаю кучу народу (ну как кучу… мои знакомые, коих, понятно, гораздо меньше чем всех программистов в любой компании подобной Google/IBM/Microsoft), которые эти designated initializers используют аж с 2012го года, когда они начали поддерживаться GCC 4.7 и Clang 3.0… и вроде у них всё работает. Может у них нет объектов со ссылками внутри или они просто всегда используют их в соотвествии со стандартами C++20… не знаю.

А у нас они оказались включены по недоразумению (они не поддерживаются в режиме -std=c++17 -pedantic, но поддерживаютс в -std=c++17 без -pedantic) — и это сразу привело к проблемам.

Эффект масштаба, однако.

А больше всего неожиданного поведения, несовместимого со стандартом я наблюдал на msvc независимо от используемых флагов.

Это — немного другая история. MSVC — это весьма часто боль, но к экспериментальным фичам это отношения не имеет.