20. что-то на замену аннотациям явы (думаю, это будет комбинация тайпклассов и сильно ослабленного варианта зависимых типов)

21. Интуитивно приемлемого варианта решения вопроса с классами Elipse & Circle.

22. для шаблонов и/или параметрического полиморфизма: возможность задавать объяснение «почему так» (в дополнение к самой ошибке)

> но некоторые до сих пор думают, что С++ - единственная альтернатива в плане производительности

давайте другие альтернативы - мы посмотрим

Продолжений, либо сопрограмм, либо хотя бы генераторов.

> Убедительная просьба фанатам других языков программирования воздержаться от комментариев.

Мы не можем, язык чешется!=) Лично мне в C++ очень не хватает Питона=)

А если более серьёзно, то не хватает встроенных средств отладки. Ну, смотри: когда в Питоне происходит exception, тебе вываливается подробная информация, что и где. Когда в плюсах происходит проблемы, чаще всего это заканчивается скупой и беспристрастной строчкой «Segmentation fault».

Ну да, и динамики мне в нём не хватает, динамики. Хотя, конечно, этого там и не должно быть...

> Ну, смотри: когда в Питоне происходит exception, тебе вываливается подробная информация, что и где

у меня тоже - останавливается прямо на месте броска, ЧЯДНТ? :)

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

поподрбнее плиз

и заодно: если бы вместо

struct C { int i; virtual int f(double x); }

писалось бы

struct C { int i; }; int f( virtual C* this, double x) { ... }

это пришло бы в порядок?

> Ну да, и динамики мне в нём не хватает, динамики. Хотя, конечно, этого там и не должно быть...

какой конткретно не хватает? (практика показывает, что не все умеют пользоваться плюсовой динамикой)

>Когда в плюсах происходит проблемы, чаще всего это заканчивается скупой и беспристрастной строчкой «Segmentation fault».

а почему gdb не используем? будет полноценный бэктрейс на месте вылета

Ну да, и динамики мне в нём не хватает, динамики.

гарантированный источник трудноуловимых багов. чем больше отловится при компиляции, тем целее будут нервы

имхо, неплохо было бы добавить throws из явы (когда в заголовке функции указывается, какие исключения она создает, а вызывающая функция в этом случае обязана их поймать или тоже объявить в throws)

Простоты, стройности и логичности.

>неплохо было бы добавить throws из явы (когда в заголовке функции указывается, какие исключения она создает, а вызывающая функция в этом случае обязана их поймать или тоже объявить в throws)

Плюсофилы такие плюсофилы. Даже историю любимого языка не знают.

Не хватает вменяемого синтаксиса, или хотя бы наличия приличного парсера, понимающего так же и семантику (до раскрытия шаблонов и вывода типов). Было бы это, были бы и IDE офигенные, и тулзы для анализа кода, и все что угодно.

Замыкания без GC не нужны. C++ с GC не нужен. Следовательно, замыкания в C++ не нужны.

>Т.е. где не могут «ВНЕЗАПНО» выпрыгнуть исключения.

а что должно происходить разыменовыванием нуля? Как в Objective-C?

>чем нейспейсы и статически члены-методы классов не устроили?

Ну в той же джаве есть квалификаторы доступа для объектов в рамках пактов. package-private. Хочется такого же...

Речь о том, чтоб по рукам за такое бил компилятор, а не рантайм и unexpected() ?

> а что должно происходить разыменовыванием нуля? Как в Objective-C?

разыменование возможно-нулл-указателя должно не пропускаться в такой блок (юзай референсы или какие другие указатели с четким разделением на возможно-нулл-указатели и точно-не-нулл-указатели)

21. Интуитивно приемлемого варианта решения вопроса с классами Elipse & Circle.

например?

Зачем хочеть изменений в бородатом языке с большим legacy?..

сабж

а так же не пользоваться ни одной сторонней библиотечной функцией? А зачем тогда это надо?

> Ну в той же джаве есть квалификаторы доступа для объектов в рамках пактов. package-private. Хочется такого же...

я полагаю это потому, что в яве нету френдов

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

> а так же не пользоваться ни одной сторонней библиотечной функцией? А зачем тогда это надо?

только теми, что сами имеют атрибут нету_внезапных_исключений

>можешь привести пример, когда классу надо сделать что-то видимым заранее не определенному числу классов, которые возможно будут добавлены в пакет?

Да. Это используюется дла написания платформенно-зависимого кода. В реализации SWT виджетов свт хендлы объектов такие. Пакет может и дает доступ лишним классам, но мне такой подход нравится больше из-за локоничности.

Эээ. Ооочень редкий юзкейз. Это стоит требовать только говоря про «демокартичность». В МПСе - да, можно создать такое расширение, это логично. Но не в базовом языке.

Кстати, еще это удобно для написания юнит - тестов: создаешь папку с тойже иерархией пакетов и тестируешь внутреннюю часть классов сколько хочешь.

В обычном C не хватает гнутых расширений. Предчувствую, что в C++ имеет место то же.

> Эээ. Ооочень редкий юзкейз. Это стоит требовать только говоря про «демокартичность». В МПСе - да, можно создать такое расширение, это логично. Но не в базовом языке.

Люди просят — значит надо.

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

> Да. Это используюется дла написания платформенно-зависимого кода. В реализации SWT виджетов свт хендлы объектов такие.

не понял, расскажи подробнее

О том и говорю. Можно как расширение языка если язык расширяем. А то юзкейзов много и описания языка размер с свод законов не охота ;)

В SWT handle (HANDLE, если не знаком с винапи - идентификатор объекта) и некоторые другие системные параметры описаны как пакедж прайват. Регулярно приходится их доставать из чужих классов из-за особенностей программирование под WinAPI. И пакетная видимость решает эту проблему.

> Зачем хочеть изменений в бородатом языке с большим legacy?..

Скажу за себя: если *вызывать готовые* функции и шаблоны, то legacy не так уж сильно проявляется и его вполне возможно обуздать специально сделанными против него механизмами. (в противовес созданию кода, натыкаясь на legacy синтаксис и legacy семантику)

Блин, всего 3 месяца в Германии, а уже так хреново говорю по-русски =/

Кстати, ты говорил у тебя были какие-то нароботки на тему расширяемого языка. Как там дела обстоят с ними? Если, конечно, не коммерческая тайна.

> Кстати, ты говорил у тебя были какие-то нароботки на тему расширяемого языка. Как там дела обстоят с ними? Если, конечно, не коммерческая тайна.

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

Да ладно, ты сознательно превратил тред в тред о DSLях ;) Идеи есть у всех, я думал ты уже прототипом занялся. Смотри не стань маниловым с пыльной книжкой раскрытой на 14 странице ;)

Мне вот даже про «демократичность» пришлось сказать типа «читайте мои посты, чтобы понять, что это такое.

Так что *проще* обсуждать конкретные фичи, которые хочется иметь, а не общие принципы.

Это безусловно.

> Идеи есть у всех, я думал ты уже прототипом занялся. Смотри не стань маниловым с пыльной книжкой раскрытой на 14 странице ;)

постараюсь

чем нейспейсы и статически члены-методы классов не устроили?

Я так понял тут про убогость хедеров речь идет.

Именно про них.

2. Наличия только контролируемой перегрузки функций.

А. подробнее? в описании D есть примеры багов языка (из-за перегрузки функций), решение — overload sets

Классы типов в Haskell.

3. Отсутствия неявных преобразований типов.

они нужны (хотя бы иногда), или речь о продвижениях?

Я не уверен, что их наличие позволит реализовать полный вывод типов.

4. Автоматического вывода типов.

в основном локального вывода типов.

Я бы предпочёл бы, чтобы объявления типов были ли бы по возможности необязательными и для top-level определений служили бы в первую очередь для документации.

7. Отсутствия бардака с вызываемыми значениями (функции, функции-члены, функциональные объекты).

а разве это можно сделать, сохранив C calling convention?

А это тут при чём? Речь о том, что должны быть только функции.

8. Гарантированной оптимизации оконечной рекурсии.

в gcc есть

1. Только частичная.

2. Я не могу рассчитывать на то, что она есть и в других компиляторах.

11. Ну и отложенные вычисления можно добавить.

lazy как в D?

Нет, lazy evaluation везде. Как в Haskell.

почти все что я хочу - уже записано в черновиках С++Ох, но пока далеко не все из этого реализовано в компиляторах

синтаксис

нормальный синтаксис, типа паскалевского

> типа паскалевского

смешно

единственное чего мне не хватает - когда он помрет...

Сказано коряво, но невероятно правильно.

Замыкания без GC не нужны.

Capability calculus позволяет делать замыкания без GC. И, на самом деле, язык с ручным управлением памятью и капабилитями я бы сильно приветствовал.

я полагаю это потому, что в яве нету френдов

Наступил на любимую мозоль.

Я тут пытался скрестить френдов с темплейтами и закомпилировать это всё PS3-шным компилером. Если кто-то считает, что GHC выдаёт невнятные сообщения об ошибках - пусть попробует повторить мой экспириенс.

>В этих лямбдах чего-то не хватает? Есть в последней VS и GCC 4.5.

Интересно, спасибо. Дождусь g++ 4.5, гляну.

>Речь о том, чтоб по рукам за такое бил компилятор, а не рантайм и unexpected() ?

конечно. а NetBeans за такое умеет бить даже в процессе кодинга, не дожидаясь компиляции

Зачем хочеть изменений в бородатом языке с большим legacy?..

Дык новый стандарт же на носу