[Ann] .Net Core roadmap
От: Sinix  
Дата: 18.07.16 08:16
Оценка: 83 (8)
Всё-таки забавные вещи по рассылке приплывают.

Вроде всё как обычно, xproj->csproj, value tasks, .NET Core Tooling, а затем внезапно такой список:

Languages (available for .NET Framework and .NET Core)


Bring functional programming concepts to .NET languages
* Tuples
* Pattern matching

Performance and Code Quality
* Value Tasks
* Ref returns
* Throw expressions
* Binary literals
* Digit separators

Developer Productivity
* Out vars
* Local functions


Нужное выделил ссылкой. Забавно всё-таки, фича сначала не попала в релиз c# 6, затем попала в планы на c# 8, затем внезапно переехала в седьмой шарп.
Там ещё новостей есть, чтоб не портить удовольствие — сами читайте :P

Ну и чтоб два раза не вставать: c# 7 work list of features опять обновили, теперь в нём помимо pattern matching акцент на кодогенерацию. Ох уж эти сказочники...
Re: [Ann] .Net Core roadmap
От: Gattaka Россия  
Дата: 18.07.16 08:29
Оценка: +2
S>Developer Productivity
S>* Out vars
S>* Local functions
S>[/q]

Костыль! Функция не должна возвращать значение через входные параметры.
Отредактировано 19.07.2016 3:37 Gattaka . Предыдущая версия . Еще …
Отредактировано 19.07.2016 3:37 Gattaka . Предыдущая версия .
Re[2]: [Ann] .Net Core roadmap
От: Sinix  
Дата: 18.07.16 08:44
Оценка: +1
Здравствуйте, Gattaka, Вы писали:

G>Костыль! Функция не должна возвращать значение через входные параметры.

Не всё, чего нет в %мой_любимый_язык%, является костылём

С интересом жду более читабельного варианта для
if (double.TryParse(text, out var parsed))
{
  // use parsed value here.
}


Ну и чтоб два раза не вставать, ваш аналог для ref?
Re[3]: [Ann] .Net Core roadmap
От: hardcase Пират http://nemerle.org
Дата: 18.07.16 08:53
Оценка: +5
Здравствуйте, Sinix, Вы писали:

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


G>>Костыль! Функция не должна возвращать значение через входные параметры.

S>Не всё, чего нет в %мой_любимый_язык%, является костылём

S>С интересом жду более читабельного варианта для

S>
S>if (double.TryParse(text, out var parsed))
S>{
S>  // use parsed value here.
S>}
S>


Откровенно говоря подобное API появилось из-за отсутствия в языке опциональных значений и кортежей а так же возможностей по их декомпозиции.
when (double.Parse(text) is Some(value))
{
  WriteLine(value);
}
/* иЗвиНите зА неРовнЫй поЧерК */
Re: [Ann] .Net Core roadmap
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 18.07.16 09:16
Оценка:
Здравствуйте, Sinix, Вы писали:

Кстати сейчас .Net Core не соответствует стандарту .NetStandart1.6. .NetStandart1.5 в студии ругается, на то, что нужен .Net 4.6.2
В проекте при указании типа проекта портативный.
Если поставить .NetStandart1.5 ругается на ошибки Object неопределен.

Когда .Net Core будет соответствовать .NetStandart1.6, или что нужно сделать, что бы студия понимала .NetStandart1.5, так как .Net 4.6.2 не нужен.
и солнце б утром не вставало, когда бы не было меня
Re[4]: [Ann] .Net Core roadmap
От: Sinix  
Дата: 18.07.16 09:27
Оценка: +3 -4 :))
Здравствуйте, hardcase, Вы писали:

H>Откровенно говоря подобное API появилось из-за отсутствия в языке опциональных значений и кортежей а так же возможностей по их декомпозиции.

Нафиг не нужны они в шарпе. Точно так же как и тюплы, если честно.
И то и то — инструмент для API на выброс, где накосячил — ну и ладно.

В взрослых проектах выгодней один раз заморочиться с API, но после этого не писать подобный треш:
when (double.Parse(text) is Some(value))
{
  WriteLine(value);
}

в сотнях и тысячах мест после каждого вызова. Мы уже проходили эти грабли с HRESULT. Мало что ли?
Re[2]: [Ann] .Net Core roadmap
От: Sinix  
Дата: 18.07.16 09:29
Оценка: 6 (1)
Здравствуйте, Serginio1, Вы писали:

S>Кстати сейчас .Net Core не соответствует стандарту .NetStandart1.6. .NetStandart1.5 в студии ругается, на то, что нужен .Net 4.6.2

Дык .NET Core Tooling всё ещё RC, релиз осенью будет. Если опять ничего внезапно(tm) не вылезет.
Re[5]: [Ann] .Net Core roadmap
От: Jack128  
Дата: 18.07.16 09:37
Оценка: +4
Здравствуйте, Sinix, Вы писали:


S>В взрослых проектах выгодней один раз заморочиться с API, но после этого не писать подобный треш:

S>
S>when (double.Parse(text) is Some(value))
S>{
S>  WriteLine(value);
S>}
S>

S>в сотнях и тысячах мест после каждого вызова. Мы уже проходили эти грабли с HRESULT. Мало что ли?

А можно пояснить, чем Option<double> TryParse(string s) трешовее bool TryParse(string s, out double value)?

Update:
Просто я не могу понять эту логику:
1) Вводим тучу методов, а-ля TryParse(string s, out XXX value)
2) Вводим в язык ПМ.
3) Вместо того, чтоб добавить Option<XXX> TryParse(string s), который отлично ложится на пункт 2), вводим в язык новую конструкцию, облегчающую использование исходного TryParse
Отредактировано 18.07.2016 9:51 Jack128 . Предыдущая версия .
Re[6]: [Ann] .Net Core roadmap
От: Sinix  
Дата: 18.07.16 09:57
Оценка: -4
Здравствуйте, Jack128, Вы писали:

J>А можно пояснить, чем Option<double> TryParse(string s) трешовее bool TryParse(string s, out double value)?


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

Как обычно, возможность сделать выбор на практике означает необходимость делать выбор: пользователи будут вынуждены или писать дополнительные костыли в виде match, или пробрасывать Option дальше, заражая весь код так же, как это делает await. Только от последнего пользы на порядок больше.

В общем идея странная, особенно если учитывать, что у шарпа уже есть удобный синтаксис для nullable values и с введением not null references необходимость в Option отпадёт окончательно.
Re[6]: [Ann] .Net Core roadmap
От: Sinix  
Дата: 18.07.16 11:03
Оценка: 1 (1)
Здравствуйте, Jack128, Вы писали:

J>Update:

J>Просто я не могу понять эту логику:
J>1) Вводим тучу методов, а-ля TryParse(string s, out XXX value)
J>2) Вводим в язык ПМ.
J>3) Вместо того, чтоб добавить Option<XXX> TryParse(string s), который отлично ложится на пункт 2), вводим в язык новую конструкцию, облегчающую использование исходного TryParse

То, что у тебя появился новый инструмент вовсе не означает необходимость использовать.

Не, есть конечно ортодоксы, которые предпочитают всегда и везде использовать var
Автор: Sinix
Дата: 02.04.16
или method group
Автор: Sinix
Дата: 04.03.11
, ловить грабли с extension methods
Автор: Sinix
Дата: 20.04.16
или с string interpolation
Автор: Sinix
Дата: 31.03.16
и тыды и тыпы. Причём не по какой-то объективной причине, а просто потому что фишка появилась / анализ кода посоветовал.

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

Сравни сам
if (double.TryParse(text, out var parsed))
{
  WriteLine(parsed);
}

// vs
if (double.TryParse(text) is Some(var parsed)) // в c#7/8 оно примерно так выглядит
{
  WriteLine(parsed);
}

Про то, как будет выглядеть метод с парой out — не советую. Съедят


Ну, или (для switch — псевдокод, синтаксис может поменяться):
var data = WebHelpers.TrySendRequest(param)?.Result.SomeField?.ToString();

// vs
var data = WebHelpers.TrySendRequest(param) switch(
    case None: None.From<string>();
    case Some x: x.Result.SomeField switch(
        case None y: y;
        case Some z: z.ToString()));

и теперь представляем, что второй вариант будет использоваться по всему коду. Т.е. не один раз в порядке "вау, мы умеем в PM", а в сотнях и тысячах мест и что поддерживать этот праздник жизни тебе. Впечатлило?

Ну так вот, перед тем, как что-то предлагать, надо хорошо представлять что в результате получится. А то как всегда, "но я же хотел совсем не этого", ага.
Re[2]: Оффтопик от граммар-наци
От: Qbit86 Кипр
Дата: 18.07.16 11:39
Оценка: +1
Здравствуйте, Serginio1, Вы писали:

S>Кстати сейчас .Net Core не соответствует стандарту .NetStandart1.6. .NetStandart1.5 в студии ругается, на то, что нужен .Net 4.6.2

S>Если поставить .NetStandart1.5 ругается на ошибки Object неопределен.
S> Когда .Net Core будет соответствовать .NetStandart1.6, или что нужно сделать, что бы студия понимала .NetStandart1.5, так как .Net 4.6.2 не нужен.

Слово «standard» в английском пишется с буквой «d» на конце.
Глаза у меня добрые, но рубашка — смирительная!
Re[7]: [Ann] .Net Core roadmap
От: hardcase Пират http://nemerle.org
Дата: 18.07.16 11:45
Оценка: +3
Здравствуйте, Sinix, Вы писали:

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


У пользователя и так есть выбор: Parse vs TryParse. А также есть выбор написать TryParse без проверки успешности разбора. В случае с вариантным значением у него вообще не будет выбора написать код без проверки результата. Но это все уже совсем иная история и не про C#.
/* иЗвиНите зА неРовнЫй поЧерК */
Re[7]: [Ann] .Net Core roadmap
От: Jack128  
Дата: 18.07.16 11:47
Оценка: 1 (1) +1
Здравствуйте, Sinix, Вы писали:

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


J>>Update:

J>>Просто я не могу понять эту логику:
J>>1) Вводим тучу методов, а-ля TryParse(string s, out XXX value)
J>>2) Вводим в язык ПМ.
J>>3) Вместо того, чтоб добавить Option<XXX> TryParse(string s), который отлично ложится на пункт 2), вводим в язык новую конструкцию, облегчающую использование исходного TryParse

S>То, что у тебя появился новый инструмент вовсе не означает необходимость использовать.


S>Не, есть конечно ортодоксы, которые предпочитают всегда и везде использовать var
Автор: Sinix
Дата: 02.04.16
или method group
Автор: Sinix
Дата: 04.03.11
, ловить грабли с extension methods
Автор: Sinix
Дата: 20.04.16
или с string interpolation
Автор: Sinix
Дата: 31.03.16
и тыды и тыпы. Причём не по какой-то объективной причине, а просто потому что фишка появилась / анализ кода посоветовал.


S>Но это не значит, что остальным надо поступать так же.


S>Сравни сам

S>
S>if (double.TryParse(text, out var parsed))
S>{
S>  WriteLine(parsed);
S>}

S>// vs
S>if (double.TryParse(text) is Some(var parsed)) // в c#7/8 оно примерно так выглядит
S>{
S>  WriteLine(parsed);
S>}
S>

S>Про то, как будет выглядеть метод с парой out — не советую. Съедят

if (MyParser.TryParse(text, out var left, out var right) { WriteLine($"{left} - {right}") }
if (MyParser.TryParse(text) is Some(var parsed)) { WriteLine($"{parsed.Left} - {parsed.Right}") }

не, те хочется сразу по переменным разложить parsed, то по идее, что то такое должно сработать:
if (MyParser.TryParse(text) is Some (( var left, var right ))) { WriteLine($"{left} - {right}") } // ага, двойные скобки -)

Ну и два out параметра сами по себе тот еще запашок имеют..


Ну из твоих примеров, я вижу, что лучший вариант, использование Nullable + допилить PM, чтоб это был PM, а не тупой typetest.
Тогда можно было и так:
var data = WebHelpers.TrySendRequest(param)?.Result.SomeField?.ToString();

и так писать:
if (MyDouble.TryParse(text) is (true, var parsed)) // double? MyDouble.TryParse(string text)
{
   WriteLine(parsed);
}


А на счет out var, если я правильно понял, то if (int.TryParse(str, out var value) {} — value видно только внутри скобок
Тогда такой код:
    if (!int.TryParse(str, out var value)) return false;
    // тут юзаем value


будет в пролете. Если так, то уж совсем криво этот синтаксис выглядит.
Отредактировано 18.07.2016 21:08 Jack128 . Предыдущая версия .
Re[8]: [Ann] .Net Core roadmap
От: Sinix  
Дата: 18.07.16 12:20
Оценка:
Здравствуйте, Jack128, Вы писали:

J>не, те хочется сразу по переменным разложить parsed, то по идее, что то такое должно сработать:

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

J>Ну из твоих примеров, я вижу, что лучший вариант, использование Nullable + допилить PM, чтоб это был PM, а не тупой typetest.

Угу, именно к этой мысли и пытался подвести. Большая часть инженерии заключается в умении _не_ использовать инструмент там, где он не нужен.

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


J>А на счет out var, если я правильно понял, то if (int.TryParse(str, out var value) {} — value видно только внутри скобок

J>Тогда такой код:... будет в пролете. Если так, то уж совсем криво этот синтаксис выглядит.

Как раз из-за вот этого момента out var и не попали в c#6, насколько помню.

Правильный вариант обсуждается до сих пор и главный аргумент за текущее поведение — схожесть с pattern matching:

The reason for this rule is that we expect people to often write code like

if (o is FooNode node && node.Whatever) { ... code using node ... } else
if (Something && o is BarNode node) { ... code using node ... } else
if (o is BazNode node) { ... code using node ... }


and we don't want to force them to have to think up new names for every node. ...
Also we don't want different but overlapping scoping rules for pattern variables and these "out" variables.

Re: [Ann] .Net Core roadmap
От: VladD2 Российская Империя www.nemerle.org
Дата: 18.07.16 20:04
Оценка:
Здравствуйте, Sinix, Вы писали:

S>Bring functional programming concepts to .NET languages

S>* Tuples
S>* Pattern matching

Бебилы ...! (ц)

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

Когда же в МС в команду дотнета возьмут тех кто разбирается в ФП?

S>Performance and Code Quality

S>* Value Tasks

А это что?

S>* Throw expressions


А это?

S>* Binary literals


И тут не очень ясно о чем речь.

S>* Digit separators


Это только к Шарпу отношение имеет. Причем тут донтет?

S>Developer Productivity

S>* Out vars
S>* Local functions
S>[/q]

Давно пора, но это опять же фича конкретного языка. В Немерле и ФШарпе она есть от рождения.

S>Нужное выделил ссылкой. Забавно всё-таки, фича сначала не попала в релиз c# 6, затем попала в планы на c# 8, затем внезапно переехала в седьмой шарп.


Тормозят они, похоже. Очень экстенсивная разработка у них.

S>Ну и чтоб два раза не вставать: c# 7 work list of features опять обновили, теперь в нём помимо pattern matching акцент на кодогенерацию. Ох уж эти сказочники...


Да, уж.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: [Ann] .Net Core roadmap
От: VladD2 Российская Империя www.nemerle.org
Дата: 18.07.16 20:25
Оценка: 26 (3)
Здравствуйте, Sinix, Вы писали:

S>С интересом жду более читабельного варианта для

S>
S>if (double.TryParse(text, out var parsed))
S>{
S>  // use parsed value here.
S>}
S>


Я бы предпочел F#-пный вариант, когда функция с out-параметрами автоматически преобразуется к реверси возвращающий кортеж.
if (double.TryParse(text) is (true, parsed))
{
  // use parsed value here.
}


S>Ну и чтоб два раза не вставать, ваш аналог для ref?


Тоже что и в прошлом случае, но для ref-параметр не удаляется из сигнатуры, а заменяется на не ref.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: [Ann] .Net Core roadmap
От: VladD2 Российская Империя www.nemerle.org
Дата: 18.07.16 20:29
Оценка: +4
Здравствуйте, Sinix, Вы писали:

S>В взрослых проектах выгодней один раз заморочиться с API, но после этого не писать подобный треш:

S>
S>when (double.Parse(text) is Some(value))
S>{
S>  WriteLine(value);
S>}
S>


Трешь — это что приходится писать в Шарпе сейчас. На фиг искать разные извращения, когда хороший выход из ситуации придуман 30 лет назад?

Единсвенное что нужно сделать — это сделать так, чтобы кортежи были дешевы в применении, чтобы люди не экономили на их использовании. Если сделать как в F#, т.е. генерить код с аут/реф-параметры, а в синтаксисе представлять такие функции как возвращающие кортеж, то получится и быстро, и красиво.

Ну, а ты немного поменяешь привычку и потом с улыбкой этот свой пост будешь вспоминать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: [Ann] .Net Core roadmap
От: VladD2 Российская Империя www.nemerle.org
Дата: 18.07.16 20:30
Оценка: +1 :))
Здравствуйте, Sinix, Вы писали:

S>Дык .NET Core Tooling всё ещё RC, релиз осенью будет. Если опять ничего внезапно(tm) не вылезет.


Традиции нельзя нарушать. Так что должно вылезти.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: [Ann] .Net Core roadmap
От: Sinix  
Дата: 18.07.16 20:40
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Бебилы ...! (ц)

VD>Ни для того, ни для другого поддержка в рантайме не нужна.

Ну блииин, для таких набросов у нас есть специально обученные люди, не надо у них хлеб отбивать
В рантайме правок нет. Речь про правки в компиляторах, они входят в состав тулинга, поэтому и упомянуты как часть roadmap.

VD>А это что?

Не-не-не, я уже наспорился на тему "шарп отстой, потому что не как в N" Если у кого есть желание объяснять — велкам
Re[7]: [Ann] .Net Core roadmap
От: VladD2 Российская Империя www.nemerle.org
Дата: 18.07.16 20:42
Оценка: +3
Здравствуйте, Sinix, Вы писали:

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


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

S>Как обычно, возможность сделать выбор на практике означает необходимость делать выбор: пользователи будут вынуждены или писать дополнительные костыли в виде match, или пробрасывать Option дальше, заражая весь код так же, как это делает await. Только от последнего пользы на порядок больше.


Пользователю и так нужно написать if чтобы сделать проверку возвращаемого значения или каким-то образом возвращать (пробрасывать, как ты сказал) знание о том, что данных нет или данные есть.

Текущее решение позволяет спокойно (в том числе и случайно) опускать проверку наличия значения. Приседание с объявлением переменной в аргументе как раз и вводится, чтобы упростить жизнь людям. Именно по этому ограничивается область видимости переменной (if-ом).

Кортеж и ПМ — это более универсальное решение не требующее костылей вроде этого. Оно заставляет проверить наличие значения перед его использованием и сокращает количество сущностей которые нужно контролировать.

S>В общем идея странная, особенно если учитывать, что у шарпа уже есть удобный синтаксис для nullable values и с введением not null references необходимость в Option отпадёт окончательно.


В этом плане удобного в Шарпе ничего не. В нем есть набор косяков и попытки нивелировать их костылями.

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