Есстественно, что имеется ввиду язык, на котором вы специализируетесь, т.е. если вы пишете на ЯП "А", но раз в неделю вам приходится написать 10 строчек на ЯП "Б", то не надо писать о "Б".

Пожалуйста, выносите в заголовок ответа название языка.

Очень надеюсь, что ветка не скатися в холливар.

всё.
особенно синтаксис унаследованный от Си.

Здравствуйте, Abyx, Вы писали:

A>всё.
A>особенно синтаксис унаследованный от Си.

Очень красноречиво.
Можно хотя-бы о синтаксисе немного конкретнее?

Здравствуйте, Философ, Вы писали:

Ф>Можно хотя-бы о синтаксисе немного конкретнее?

был язык Си. (и счя зачем-то есть)
у него был хороший синтаксис и хорошие фичи. дцать лет назад — хороший.
сейчас 2011й год, в С++11 всё тот же синтаксис Си, который устарел на десятилетия.

"T[N]* variable" это читабельнее чем "T(*variable)[N]", потому что тип существует сам со себе, отдельно от идентификаторов переменных и alias'ов

если "V(1)" это вызов конструктора типа V, или вызов функции V,
если "U x(y);" это переменная x типа U, в конструктор которой передается y,
то "U x(V(y));" должно быть переменной x, а не объявлением функции.

"заголовочные" файлы устарели,
возможность написать "#define min ..." в заголовочном файле это совсем плохо

etc, etc.

Здравствуйте, Философ, Вы писали:

Ф>Что вам не нравится в языке, на котором вы пишете

В C# не хватает возможности ограничить область видимости «let-привязки» вычисляемым выражением: http://bik-top.livejournal.com/50984.html.

Здравствуйте, Qbit86, Вы писали:

Ф>>Что вам не нравится в языке, на котором вы пишете

Q>В C# не хватает возможности ограничить область видимости «let-привязки» вычисляемым выражением: http://bik-top.livejournal.com/50984.html.

А что, фигурные скобки уже запретили?
Кроме того, автор решая задачу, настолько увлекся, что забыл свой же изначальный посыл — упростить "понимание и рефакторинг кода". Если первоначальный код с какой-то натяжкой еще можно согласиться и признать непонятным, то окончательный вариант просто ужасен.

Здравствуйте, Философ, Вы писали:

Ф>Пожалуйста, выносите в заголовок ответа название языка.

Лично мне:

1. const для локальных переменных
2. паттерн-матчинг
3. нормалный синтаксис для туплов
4. локальные функции с нормальным синтаксисом
5. вывод типов для приватных методов
6. yield в лямбдах
7. string interpolation (хз как правильно называть)
8. Свободные функции (без класса)
9. Вызов extension-методов без this
10. Поддержка паралельности на уровне синтаксиса (async не щупал)

Ф>Очень надеюсь, что ветка не скатися в холливар.

Скатится.

Здравствуйте, Lloyd, Вы писали:

Q>>В C# не хватает возможности ограничить область видимости «let-привязки» вычисляемым выражением: http://bik-top.livejournal.com/50984.html.

L>А что, фигурные скобки уже запретили?

Фигурные скобки были упомянуты:

«Можно использовать для sin_φ естественные ограничители скоупа:

double y;
{
    double const sin_φ = sin(φ);
    y = 0.5 * log((1.0 + sin_φ) / (1.0 - sin_φ));
}

Но теперь переменная y перестаёт быть константой, помимо объявлений/определений появляются присваивания. Усугубляется тем, что всё вышеизложенное касается не только переменной y, но и любой другой переменной в примере.»

L>Если первоначальный код с какой-то натяжкой еще можно согласиться и признать непонятным, то окончательный вариант просто ужасен. :down:

Он ужасен только в Си-подобных языках, в ML-подобных языках всё хорошо. «Окончательный вариант» — всего лишь обоснование принципиальной возможности добиться нужного поведения в императивных языках с анонимными функциями — просто на основании того, что обсуждаемые конструкции являются не более чем синтаксическим сахаром в рамках лямбда-исчисления:

let x : σ = N in M ≝ (λx : σ. M) N
M where x : σ = N  ≝ (λx : σ. M) N

Никто не настаивает на использовании приведённых C#-аналогов требуемых ML-конструкций. Если бы я считал их практичными, я б не жаловался в этот тред на недостаток нужных мне возможностей :)

Здравствуйте, Qbit86, Вы писали:

L>>А что, фигурные скобки уже запретили?

Q>Фигурные скобки были упомянуты:
Q>

«Можно использовать для sin_φ естественные ограничители скоупа:
Q>

Q>double y;
Q>{
Q>    double const sin_φ = sin(φ);
Q>    y = 0.5 * log((1.0 + sin_φ) / (1.0 - sin_φ));
Q>}
Q>

Q>Но теперь переменная y перестаёт быть константой, помимо объявлений/определений появляются присваивания. Усугубляется тем, что всё вышеизложенное касается не только переменной y, но и любой другой переменной в примере.»

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

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

Q>Он ужасен только в Си-подобных языках, в ML-подобных языках всё хорошо.

Ну как же так, совсем не хорошо: radiansPerDegree фигурирует в выражении только как правый операнд оператора "*", однако "светится" и там, где его быть не полжно (справа). Непорядок.

Здравствуйте, Lloyd, Вы писали:

L>Лично мне:

L>1. const для локальных переменных
L>2. паттерн-матчинг
L>3. нормалный синтаксис для туплов
L>4. локальные функции с нормальным синтаксисом
L>5. вывод типов для приватных методов
L>6. yield в лямбдах
L>7. string interpolation (хз как правильно называть)
L>8. Свободные функции (без класса)
L>9. Вызов extension-методов без this
L>10. Поддержка паралельности на уровне синтаксиса (async не щупал)
11. Поддержка "ленивых" const переменных на уровне синтаксиса.

Здравствуйте, Философ, Вы писали:

Ф>Есстественно, что имеется ввиду язык, на котором вы специализируетесь, т.е. если вы пишете на ЯП "А", но раз в неделю вам приходится написать 10 строчек на ЯП "Б", то не надо писать о "Б".

Ф>Пожалуйста, выносите в заголовок ответа название языка.

Ф>Очень надеюсь, что ветка не скатися в холливар.

C++ невозможно отличить создание временнoгo обьекта от вызова функции:

int a = foo(B(x)); — что здесь B(x) ?

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

Здравствуйте, Lloyd, Вы писали:

L>1. const для локальных переменных
L>2. паттерн-матчинг
L>3. нормалный синтаксис для туплов
L>4. локальные функции с нормальным синтаксисом
L>5. вывод типов для приватных методов
L>6. yield в лямбдах
L>7. string interpolation (хз как правильно называть)
L>8. Свободные функции (без класса)
L>9. Вызов extension-методов без this
L>10. Поддержка паралельности на уровне синтаксиса (async не щупал)

Хотел перечислить фичи Nemerle которых мне не хватает в C#, но ты меня опередил
11. метапрограммирование

Здравствуйте, Ziaw, Вы писали:

Z>Хотел перечислить фичи Nemerle которых мне не хватает в C#, но ты меня опередил
Z>11. метапрограммирование

Не нужно. В конечном итоге приведет к адовому кол-ву несовместимых "языков". Фича интересная "на поиграться", но в реальной жизни лучше лишний раз перестраховаться, чем потом разгребать тонны "гениальных" свистелок.

Здравствуйте, Слава, Вы писали:

С>C++ невозможно отличить создание временнoгo обьекта от вызова функции:

С>int a = foo(B(x)); — что здесь B(x) ?

А это действительно важно? Конструктор ведь и есть функция создающая объект.

C++, неявное преобразование signed <-> unsigned

I>C++, неявное преобразование signed <-> unsigned

варнинги же

Здравствуйте, Lloyd, Вы писали:

L>Ну так это совсем другая проблема — невозможность объявить такую перепенную константной, хотя она очевидно таковой является.

Так даже если такую возможность добавить в C#, в данном случае воспользоваться ей будет нельзя (по той же причине, по которой нельзя в C++).

Здравствуйте, igna, Вы писали:

L>>Ну так это совсем другая проблема — невозможность объявить такую перепенную константной, хотя она очевидно таковой является.

I>Так даже если такую возможность добавить в C#, в данном случае воспользоваться ей будет нельзя (по той же причине, по которой нельзя в C++).

Почему?

Здравствуйте, Lloyd, Вы писали:

L>Почему?

Там же написано: потому что "помимо объявлений/определений появляются присваивания".

Здравствуйте, Слава, Вы писали:

С>C++ невозможно отличить создание временнoгo обьекта от вызова функции:
С>int a = foo(B(x)); — что здесь B(x) ?

И не надо. Считай конструктор функцией, возвращающей экземпляр объекта. Тем более, что это позволяет создавать конструктороподобные функции с сохранением синтаксиса:

class Point
{
    Point(double x, double y);
    . . .
};

Point polarPoint(double ρ, double φ);

doSomething(Point(1, 2));
doSomething(polarPoint(3, 4));

С>это как бы первое, что пришло на ум. а вообще иногда бывают такие завороты, что вообще не поймёш что к чему. Но сейчас не вспоминается.

typename. В половине случаев обязательно, в остальных случаях недопустимо, что затрудняет написание макросов. А кроме того, я считаю, что синтаксически оно ставится не туда:

// сейчас
typename std::iterator_traits<I>::reference r = c.front();

// логичнее
std::iterator_traits<I>::typename reference r = c.front();

поскольку вся суть typename здесь в том, чтобы сказать, что «reference» есть имя типа (type name), вот возле этого идентификатора ему бы и стоило находиться. Заодно были бы решены вот такие проблемы:

#define HOMEMADE_TYPEOF(x) /* typename? */ SomeHelper<sizeof(darkWizardry(x))>::type

template <class X>
void f(X x)
{
    typedef HOMEMADE_TYPEOF(x) T;
    // typedef typename SomeHelper<. . .>::type T;
    // требуется typename, чтобы отметить идентификатор type как имя типа

    int const y = HOMEMADE_TYPEOF(x)::some_const;
    // int const y = SomeHelper<. . .>::type::some_const;
    // требуется отсутствие typename, иначе оно бы распространялось на имя some_const
}

// то ли дело, если typename стоит перед своим идентификатором:

#define HOMEMADE_TYPEOF(x) SomeHelper<sizeof(darkWizardry(x))>::typename type

template <class X>
void f(X x)
{
    typedef HOMEMADE_TYPEOF(x) T;
    // typedef SomeHelper<. . .>::typename type T;
    // type должным образом отмечен как имя типа

    int const y = HOMEMADE_TYPEOF(x)::some_const;
    // int const y = SomeHelper<. . .>::typename type::some_const;
    // type — имя типа (что избыточно, :: и так говорит об этом), some_const — нет
}