Next C++ Standard: «“Nominal” vs “Structural”» or «Concepts Must Go!»

[dememax]

Работник Биг-Блю пишет по результатам июльской встречи комитета по стандартизации Си++ о значительном изменении, можно сказать, "шаге назад" в проекте следующего стандарта языка программирования Си++ - отказе от Concepts.

За разъяснениями автор поста отправляет к июньской бумаге автора языка Си++ "Simplifying the use of concepts", в которой Бьёрн Страуструп разъясняет сформировавшиеся в языке подходы к решению задач, подытоживает достигнутое, в частности:

"I conjecture that a major reason that generic programming succeeded in C++ where it failed in languages using object-oriented programming with explicitly specified interfaces (as in C++ and Java – a nominal type system) is that templates are essentially structural (and similar to many dynamically-typed languages where OO techniques have succeeded in supporting variants of generic programming). The added freedom of expression and flexibility provided by templates over class hierarchies with explicit interfaces has been a major advantage to C++ programmers, arguably the key to modern C++. That freedom has also been a significant source of problems (especially poor compile-time error handling).

I see concepts as a way of compensating for the weaknesses of templates stemming from their extreme structural nature. The major design challenge is to do this without pushing the type system so far over into the nominal camp that we reintroduce the problems of rigidity, verbosity (notational overhead) and overspecification (explicitly specifying details that could be deduced) found with class hierarchies and object-oriented programming. The way I see it, catching the errors we see with template arguments is easy: we just use an equivalent of nominal typing (such as classes). The challenge is to do just enough of this without going so far as to damage generic programming, performance, etc. As my old advisor used to say (in the context of security) “protection is easy, it’s granting access that’s hard.”"

Upd: Ещё, очень в тему: http://itman.livejournal.com/253147.html?thread=2433243#t2433243
More links: Danny Kalev Blog, August 7, 2009: An Interview with Bjarne Stroustrup about Concepts and C++'s Future

Comments

[itman.livejournal.com]

Здраво глядя на весь это балаган, давно пора бы это заморозить. Не надо делать из плюсов язык для всех. Есть и другие языки.

Re: "...балаган, давно пора бы это заморозить..."

[dememax]

То, что язык Си++ не для всех - это ежу понятно.
Даже если очень захотят, практически невозможно сделать входной барьер низким.
Kevlin Henney, который подрабатывает консультациями, жалуется, что ему придётся объяснять очень продвинутую и нужную, но уж очень специфичную вещь (на 45-ой минуте видео, когда он переходит к "Value-Based Programming", там есть "C++0X will provide support for moving values"), которая будет включена в новый стандарт.

Никак не могу понять, что же ты предлагаешь в конце концов: заморозить разработку и принятие нового стандарта Си++?

Re: "...балаган, давно пора бы это заморозить..."

[itman.livejournal.com]

Да, есть же какие-то разумные пределы. Невозможно эту совместимость протаскивать до бесконечности.

Re: "...Невозможно эту совместимость протаскивать до бес

[dememax]

Совместимость?
Ну, насколько я понимаю, Concepts не вводили проблемы совместимости (кроме новых ключевых слов, что несущественно).

Re: "...Невозможно эту совместимость протаскивать до бес

[itman.livejournal.com]

Невозможно писать компилятор языка,
который постоянно включает новые фичи и поддерживает старые (некоторые очень странные). Еще труднее учить такой язык.

Re: "...Невозможно писать компилятор языка,..."

[dememax]

Если я не ошибаюсь, то самая неприятная особенность языка Си++ для писателей компиляторов - это его контекстно-зависимая разборка грамматики.

Re: "...Невозможно писать компилятор языка,..."

[itman.livejournal.com]

Может быть, но поддержка фич - это тоже не сахар.