Есстественно, что имеется ввиду язык, на котором вы специализируетесь, т.е. если вы пишете на ЯП "А", но раз в неделю вам приходится написать 10 строчек на ЯП "Б", то не надо писать о "Б".
Пожалуйста, выносите в заголовок ответа название языка.
Очень надеюсь, что ветка не скатися в холливар.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
Ф>Можно хотя-бы о синтаксисе немного конкретнее?
был язык Си. (и счя зачем-то есть)
у него был хороший синтаксис и хорошие фичи. дцать лет назад — хороший.
сейчас 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.
In Zen We Trust
Re: C#: Ограничение области видимости локальной переменной
Здравствуйте, Qbit86, Вы писали:
Ф>>Что вам не нравится в языке, на котором вы пишете
Q>В C# не хватает возможности ограничить область видимости «let-привязки» вычисляемым выражением: http://bik-top.livejournal.com/50984.html.
А что, фигурные скобки уже запретили?
Кроме того, автор решая задачу, настолько увлекся, что забыл свой же изначальный посыл — упростить "понимание и рефакторинг кода". Если первоначальный код с какой-то натяжкой еще можно согласиться и признать непонятным, то окончательный вариант просто ужасен.
Re: C#: const для переменных, pattern-matching, ...
Здравствуйте, Философ, Вы писали:
Ф>Пожалуйста, выносите в заголовок ответа название языка.
Лично мне:
1. const для локальных переменных
2. паттерн-матчинг
3. нормалный синтаксис для туплов
4. локальные функции с нормальным синтаксисом
5. вывод типов для приватных методов
6. yield в лямбдах
7. string interpolation (хз как правильно называть)
8. Свободные функции (без класса)
9. Вызов extension-методов без this
10. Поддержка паралельности на уровне синтаксиса (async не щупал)
Ф>Очень надеюсь, что ветка не скатися в холливар.
Скатится.
Re[3]: C#: Ограничение области видимости локальной переменно
Здравствуйте, Lloyd, Вы писали:
Q>>В C# не хватает возможности ограничить область видимости «let-привязки» вычисляемым выражением: http://bik-top.livejournal.com/50984.html.
L>А что, фигурные скобки уже запретили?
Фигурные скобки были упомянуты:
«Можно использовать для sin_φ естественные ограничители скоупа:
Но теперь переменная y перестаёт быть константой, помимо объявлений/определений появляются присваивания. Усугубляется тем, что всё вышеизложенное касается не только переменной y, но и любой другой переменной в примере.»
L>Если первоначальный код с какой-то натяжкой еще можно согласиться и признать непонятным, то окончательный вариант просто ужасен. :down:
Он ужасен только в Си-подобных языках, в ML-подобных языках всё хорошо. «Окончательный вариант» — всего лишь обоснование принципиальной возможности добиться нужного поведения в императивных языках с анонимными функциями — просто на основании того, что обсуждаемые конструкции являются не более чем синтаксическим сахаром в рамках лямбда-исчисления:
let x : σ = N in M ≝ (λx : σ. M) N
M where x : σ = N ≝ (λx : σ. M) N
Никто не настаивает на использовании приведённых C#-аналогов требуемых ML-конструкций. Если бы я считал их практичными, я б не жаловался в этот тред на недостаток нужных мне возможностей :)
Глаза у меня добрые, но рубашка — смирительная!
Re[4]: C#: Ограничение области видимости локальной переменно
Q>Но теперь переменная y перестаёт быть константой, помимо объявлений/определений появляются присваивания. Усугубляется тем, что всё вышеизложенное касается не только переменной y, но и любой другой переменной в примере.»
Ну так это совсем другая проблема — невозможность объявить такую перепенную константной, хотя она очевидно таковой является.
L>>Если первоначальный код с какой-то натяжкой еще можно согласиться и признать непонятным, то окончательный вариант просто ужасен.
Q>Он ужасен только в Си-подобных языках, в ML-подобных языках всё хорошо.
Ну как же так, совсем не хорошо: radiansPerDegree фигурирует в выражении только как правый операнд оператора "*", однако "светится" и там, где его быть не полжно (справа). Непорядок.
Re[2]: C#: const для переменных, pattern-matching, ...
Здравствуйте, 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 переменных на уровне синтаксиса.
Re: C++ невозможно отличить создание временнoгo обьекта от в
Здравствуйте, Философ, Вы писали:
Ф>Есстественно, что имеется ввиду язык, на котором вы специализируетесь, т.е. если вы пишете на ЯП "А", но раз в неделю вам приходится написать 10 строчек на ЯП "Б", то не надо писать о "Б".
Ф>Пожалуйста, выносите в заголовок ответа название языка.
Ф>Очень надеюсь, что ветка не скатися в холливар.
C++ невозможно отличить создание временнoгo обьекта от вызова функции:
int a = foo(B(x)); — что здесь B(x) ?
это как бы первое, что пришло на ум. а вообще иногда бывают такие завороты, что вообще не поймёш что к чему. Но сейчас не вспоминается.
Спасибо за внимание
Re[2]: C#: const для переменных, pattern-matching, ...
Здравствуйте, 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. метапрограммирование
Re[3]: C#: const для переменных, pattern-matching, ...
Здравствуйте, Ziaw, Вы писали:
Z>Хотел перечислить фичи Nemerle которых мне не хватает в C#, но ты меня опередил Z>11. метапрограммирование
Не нужно. В конечном итоге приведет к адовому кол-ву несовместимых "языков". Фича интересная "на поиграться", но в реальной жизни лучше лишний раз перестраховаться, чем потом разгребать тонны "гениальных" свистелок.
Re[2]: C++ невозможно отличить создание временнoгo обьекта о
Здравствуйте, Lloyd, Вы писали:
L>Ну так это совсем другая проблема — невозможность объявить такую перепенную константной, хотя она очевидно таковой является.
Так даже если такую возможность добавить в C#, в данном случае воспользоваться ей будет нельзя (по той же причине, по которой нельзя в C++).
Re[6]: C#: Ограничение области видимости локальной переменно
Здравствуйте, igna, Вы писали:
L>>Ну так это совсем другая проблема — невозможность объявить такую перепенную константной, хотя она очевидно таковой является.
I>Так даже если такую возможность добавить в C#, в данном случае воспользоваться ей будет нельзя (по той же причине, по которой нельзя в C++).
Почему?
Re[7]: C#: Ограничение области видимости локальной переменно
Здравствуйте, Слава, Вы писали:
С>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 — нет
}