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

J>>А в чем смысл?? чем это лучше public Point Move(int dx, int dy) { return new Point(X + dx, Y + dy); }
J>>return убрали, да вместо скобок "=>" поставили ?? чёто не очень.

A>Можно предположить что на Expression можно будет разбирать отдельные методы а не только выражения. Как в F#.

Сильно вряд ли. Это ограничение искусственное. Процессоры Expression очевидно не умеют интерпретировать весь C#, только экспрешны. Сильно вряд ли Linq Provider будет в курсе, как интерпретировать switch или yield. Вот и обрезали до экспрешнов.

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

A>>Можно предположить что на Expression можно будет разбирать отдельные методы а не только выражения. Как в F#.
J>Не понял, честно говоря. Можно примером пояснить?
ровать
Я имел в виду Code Quotations F#. Но ошибся.

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

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

J>>>А в чем смысл?? чем это лучше public Point Move(int dx, int dy) { return new Point(X + dx, Y + dy); }
J>>>return убрали, да вместо скобок "=>" поставили ?? чёто не очень.

A>>Можно предположить что на Expression можно будет разбирать отдельные методы а не только выражения. Как в F#.

I>Сильно вряд ли. Это ограничение искусственное. Процессоры Expression очевидно не умеют интерпретировать весь C#, только экспрешны. Сильно вряд ли Linq Provider будет в курсе, как интерпретировать switch или yield. Вот и обрезали до экспрешнов.

Switch и пр. существуют в природе http://msdn.microsoft.com/ru-ru/library/dd268013(v=vs.110).aspx, только сахара нет.
Чем черт не шутит, добавят в C# 7.0

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

A>>>Можно предположить что на Expression можно будет разбирать отдельные методы а не только выражения. Как в F#.

I>>Сильно вряд ли. Это ограничение искусственное. Процессоры Expression очевидно не умеют интерпретировать весь C#, только экспрешны. Сильно вряд ли Linq Provider будет в курсе, как интерпретировать switch или yield. Вот и обрезали до экспрешнов.

A>Switch и пр. существуют в природе http://msdn.microsoft.com/ru-ru/library/dd268013(v=vs.110).aspx, только сахара нет.
A>Чем черт не шутит, добавят в C# 7.0

А я где то сказал, что этого нет в природе ? Ни один из LInq провайдеров не умеет этих свичей. Так понятно ?

Здравствуйте, Аноним, Вы писали:

А>//primary constructors —
А>public class Point(int x, int y) { }

Кто-нибудь может объяснить, что это? А то все читают с таким видом, будто это есть во всех языках и только c# наконец до этого докатился!

А>//static type using statements —
А>using System.Math;

Это как в Немерле — импорт класса и вызов в коде статических методов без указания класса?

А>//monadic null checking —
А>if (points?.FirstOrDefault()?.X ?? -1) { }

Больше говнокода! Даёшь жабоскрипт!
Мрак, если откровенно.

А что там народ заикался про множественный return? Разве это возможно? (без хаков) Мой эксперимент на MSIL показал, что возврат из функции с более чем одним элементом на стеке сразу разрывает на куски. Т.е. "напрямую" не получится, значит опять индусские дуроломы прикрутят на изоленте hidden class, который будет прятать в себе массив возвращаемых значений.

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

A>Можно предположить что на Expression можно будет разбирать отдельные методы а не только выражения. Как в F#.

Это было бы чересчур смелое предположение.

Здравствуйте, Аноним, Вы писали:

А>А когда будет что нибудь более официальное на этот счет? И будут ли какие то более интересные фичи, или это весь список нововведений?

Пока что это список идей для гипотетических будущих версий C#. Некоторые из этих идей прототипировались, однако не нужно воспринимать пару слайдов на конференции как официальное объявление новых фич или как обязательство реализовать их в ближайшей следующей версии. Скорее, это приглашение к неформальной дискуссии, чтобы лучше понять, в чём нуждаются разработчики.

Здравствуйте, <Аноним>, Вы писали:

А>Имхо, какой то хоть и полезный но хлам.

Фокус этого релиза — новый компилятор и language service в студии, глобальных фич ожидать не стоит. И это, на самом деле, хорошо, потому что ели бы были глобальные фичи, мелочи бы опять остались нереализоованными.

Здравствуйте, <Аноним>, Вы писали:

А>>//primary constructors —
А>>public class Point(int x, int y) { }
А>Кто-нибудь может объяснить, что это? А то все читают с таким видом, будто это есть во всех языках и только c# наконец до этого докатился!

Синтаксический сахар. Транслируется в такое:

public class Point
{
  private int x;
  private int y;

  public Point(int x, int y)
  {
    this.x = x;
    this.y = y;
  }  
}

А>>//static type using statements —
А>>using System.Math;
А>Это как в Немерле — импорт класса и вызов в коде статических методов без указания класса?

Да. Причем для extension методов тоже будет работать.

А>>//monadic null checking —
А>>if (points?.FirstOrDefault()?.X ?? -1) { }

А>Больше говнокода! Даёшь жабоскрипт!
А>Мрак, если откровенно.

Мрак в чем? Если в синтаксисе, то это не окончательный вариант.

А>А что там народ заикался про множественный return? Разве это возможно?

Это ты о чем вообще?

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

J>А в чем смысл??

В том что меньше мусорного кода.

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

А>>//read only auto-properties —
А>>public int X { get; } = x;
_NN>А как это работает ?

private int _x = x;
public int X { get { return x; } }

_NN>Что означает "= x" ? Это инициализация или имя переменной ?

Это параметр primary constructor. Который в предыдущем примере.

А>>public Point Move(int dx, int dy) => new Point(X + dx, Y + dy);
_NN>Проще разрешить выражения и убрать 'return', тогда не нужно ничего придумывать и использовать обычные свойства и методы.

Это сломает совместимость. Впрочем, кое что на эту тему, возможно, будет:

var a = (var x = Foo(); var y = Bar(x); FooBar(y));

А>>//params for enumerables —
А>>public Point Average(params IEnumerable<Point> points) { }
_NN>Я так понимаю для этого нужно менять рантайм. Верно ?

Нет. params это синтаксический сахар, рантайм менять не нужно.

А>>if (points?.FirstOrDefault()?.X ?? -1) { }
_NN>Полезная фича, давно реализуемая в других языках.

Вот только синтаксис ...

_NN>Хотя наверное только из конструктора выводит

Да.

А>>//inline declarations for out params —
А>>public void Foo(out var x, out var y) { }
_NN>Практикуют программирование на 'out' типах ?

Упрощают его.

_NN>Не проще ли кортежи добавить в язык ?

Нет.

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

Это испорченный телефон. На самом деле правильный вариант такой:

var x = Foo(out var x, out var y);

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

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

Скажи честно, у тебя же у самого руки по локоть в крови AST Розлина. Неужели ты всё ещё не нуждаешься в паттерн-матчинге? ПМ ведь вам самим сэкономил бы тонны кода.

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

AVK>Это испорченный телефон. На самом деле правильный вариант такой:
AVK>

AVK>var x = Foo(out var x, out var y);
AVK>

Как соотносятся x слева и справа от оператора присваивания?

Здравствуйте, Аноним, Вы писали:

А>//constructor type parameter inference —
А>var t = new Tuple(1,2); // infers Tuple<T1, T2>
А как насчет "частичного" вывода типов??
что нить типа такого:
TResult Method<TArg, TResult>(TArg arg) { ... }
var s = Method<_, string>(10); // TArg вывелось как int

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

J>Как соотносятся x слева и справа от оператора присваивания?

Никак.

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

А>>>public Point Move(int dx, int dy) => new Point(X + dx, Y + dy);
_NN>>Проще разрешить выражения и убрать 'return', тогда не нужно ничего придумывать и использовать обычные свойства и методы.

AVK>Это сломает совместимость. Впрочем, кое что на эту тему, возможно, будет:
AVK>

AVK>var a = (var x = Foo(); var y = Bar(x); FooBar(y));
AVK>

Можно тогда добавить какой-нибудь префикс типа

public noreturn int X { get { 1 } }

AVK>Это испорченный телефон. На самом деле правильный вариант такой:
AVK>

AVK>var x = Foo(out var x, out var y);
AVK>

Т.е. объявление переменной прямо из вызова метода ?

Может просто добавить вывод типов из использования для out.
Скажем, Nemerle:

mutable x, y;
def z = Foo(out x, out y);

Здравствуйте, Аноним, Вы писали:

А>http://adamralph.com/2013/12/06/ndc-diary-day-3/
А>

А>//read only auto-properties - 
А>public int X { get; } = x;
А>//property expressions - 
А>public double Distance => Sqrt(X * X + Y * Y);
А>

мне кажется, что это одно и тоже.
зачем вводить синтаксис public int X { get; } = x если и так можно будет написать public int X => x; ?

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

_NN>Можно тогда добавить какой-нибудь префикс

Вот так языки и превращаются в какашку

AVK>>Это испорченный телефон. На самом деле правильный вариант такой:
AVK>>

AVK>>var x = Foo(out var x, out var y);
AVK>>

_NN>Т.е. объявление переменной прямо из вызова метода ?

Exactly. Declaration expression называется.

_NN>Может просто добавить вывод типов из использования для out.
_NN>Скажем, Nemerle:
_NN>

_NN>mutable x, y;
_NN>def z = Foo(out x, out y);
_NN>

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

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

J>мне кажется, что это одно и тоже.

Кажется.

J>зачем вводить синтаксис public int X { get; } = x если и так можно будет написать public int X => x; ?

Потому что в первом случае это автосвойство, инициализируемое в конструкторе один раз, а во втором — вычисляемое при каждом обращении свойство.

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

I>Сильно вряд ли. Это ограничение искусственное. Процессоры Expression очевидно не умеют интерпретировать весь C#, только экспрешны. Сильно вряд ли Linq Provider будет в курсе, как интерпретировать switch или yield. Вот и обрезали до экспрешнов.

У тебя причина попутана со следствием. Linq провайдеры не интерпретируют switch, потому что генерация компилятором expressions обрезана до экспрешинов. Сделать же разбор switch не представляет особого труда. Была бы в этом необходимость.

И, кстати, yield — это сахар, ему ничего не соответствует ни в ET, ни в MSIL.