apolukhin
commented
3 years ago Antervis, 13 марта 2019, 11:48 extern тоже одна старая болезнь с++
Александр Коновалов, 19 марта 2019, 15:55 Antervis, он действительно выглядит как болезнь, но при этом мне осталось не понятно, зачем эту болезнь (если это всё же болезнь) потащили в D?
Andrey Davydov, 13 марта 2019, 18:57 Есть идея (очень неоднозначная) иметь разные диалекты языка в разных модулях. Одна из дискуссий, к примеру, тут: https://www.reddit.com/r/cpp/comments/agcw7d/c_modules_a_chance_to_clean_up_the_language/. Может быть такого рода решение удолетворит Вас?
Александр Коновалов, 19 марта 2019, 15:54 Andrey Davydov, да, по сути то же, что и я предлагаю, только на основе модулей. По факту, в моём предложении механизм не самое главное.
Перенос предложения: голоса +5, -2 Автор идеи: Александр Коновалов
В этой идеи и сам недоконца уверен, но всё же захотелось услышать мнение других.
У языка C++ есть старая "болезнь" (но для некоторых и приятная особенность): очень сильная обратная совместимость. Она ограничивает или усложняет введение нового функционала. Для хотя бы частичного решения данной проблемы есть идея указывать используемый стандарт в директиве extern (например: extern "c++11" { ... }). Таким образом, старый код можно будет обернуть данной директивой, не боясь проблем обратной совместимости. В рамках данной идеи также предлагается пропускать конструкции с невалидной строкой (а скорее даже выводить warning).
Чем хороша для этого extern? Во-первых, такой подход используется для включения C кода в C++, а также аналогичный для использования C++ и C в D. Во-вторых, есть уже готовая и проверенная языковая конструкция. В-третьих, такую конструкцию также можно использовать для кастомных расширений C++ какими-либо компиляторами (а может даже библиотеками, которые ставятся как плагины к компиляторам).
У этого подхода есть и отрицательные стороны. Во-первых, необходимость оборачивать старый код. Во-вторых, без особых приёмов оборачивания (вроде тех, которые используются в заголовочных файлах C библиотеки в C++) такой код потеряет возможность быть скомпилированным на старых версиях компиляторов, т.к. текущая реализация предполагает генерацию ошибки при использовании строки с недопустимым содержимым. В-третьих, при использовании данного подхода при подключении кастомных расширений языка, не понятно, как разрулить случаи использования разных расширений или старого стандарта с расширением.