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

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

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

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

И поэтому делегаты такие дорогие в создании и вызове.


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

Да нет там никаких юридических дебрей, вот в чём странность.
Т.е. иск юридически ничтожен.

Поэтому, в кач-ве аргументов были не юридические доводы, а "общечеловеческие", филосовские и прочий такой бред.

Это почему суды присяжных, таки, фуфел, судопроизводством должны заниматься профессионалы.

Смотри, вот ты однажды утром проснулся, взял, допустим, открытый стандарт С++, который не покрыт ни патентами, ни запретами на клонирование, ни чем бы то ни было еще.
Вот ты "форкнул" стандарт для себя, добавил нужных тебе фич, назвал С+++, написал компилятор, показал людям.

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

Есть изнанка капитализма: деньги (в т.ч. интересы инвесторов и прочее) превыше закона.


S>Возможно, мы сейчас бы жили в мире, где дотнета нет, зато есть java с value-типами и нормальными генериками, а не этой порнографией.

Не факт, достаточно посмотреть на веб.

MS вставляли палки в колеса в течении 15 лет, не давали развивать веб.
Почему? — потому что сами отставали.

MS на веб забила в итоге, бо и так IE в течении 15 лет был лучше любых альтернатив.

А потом эти отстающие с грехом пополам допилили эппловский WebKit до более-менее вменяемого состояния, выкатили Хром.
Сказали: "Вот теперь мы тоже готовы развивать веб, так давайте же его развивать!"

Но 15 лет потеряно.
Так же было бы и с джавой — это были бы такие же точно гири на ногах.

Т.е., в IT индустрии в плане стандартов происходит равнение на отстающих.
А вылезающих вперёд враждебное к друг другу до этого стадо объединившись совместно мочит выскочку, прямо как в старом советском мультике:
https://www.youtube.com/watch?v=phl_hFPBY0U


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

Имели бы одну платформу, отстающую в развитии от имеющихся сегодня лет на 15. ))

А так дотнет мог делать что хотел...
Ну и Джава ойкнула от неожиданости и тоже начала шевелиться.


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

У нас это одни и те же люди.


S>То есть анонимную локальную функцию — можно, безо всяких ворнингов, а именованную — уже нельзя.

На новый круг заход? ))
Ф-ия чиста, но блок кода — не факт.
Поэтому блоки нельзя.


S>То есть в делегате ссылаться на потенциально нечистую функцию — ок

Отродясь.


S>а в expression — уже зашквар?

Я так думаю, что из тех соображений, мол, а как нечистую ф-ию переводить в SQL?

Но ограничение всё-равно странное, бо использованный в чистой ф-ии делегат тоже в SQL не уедет, т.е. expression-to-DB провайдер ругнётся в рантайме.
Т.е., можно было бы во всех случаях выбрасывать рантайм-ошибки, в т.ч. и для выражений-блоков, если нет возможности перевести их в SQL.


V>>А как обеспечить чистоту функций на уровне языка — непонятно.
S>Это опять рационализация иррационального.

ИМХО, это еще один инструмент проектирования.

Есть же языки, которые позволяют помечать нужные ф-ии как чистые.
В таких ф-иях нельзя производить нечистые вычисления, компилятор не скомпилит.

Причём, это удобней чистых ФП-языков, т.к. ф-ия запросто может быть чистой даже если использует мутабельные переменные в своём теле.


V>>Про локальные я полностью согласен — это непредсказуемая дичь в случае Expression и обычных делегатов, т.к. не всегда очевидно, что именно захватывается и где, т.к. таких локальных ф-ий может быть несколько, но они шарят общий контекст.
S>Как видим, в случае делегатов это никому не мешает.

Откуда "мы" это видим, если у тебя проявляется та же ошибка, только теперь без ворнинга? ))

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

    var funcs = new List<Func<int>>();

    for(int i = 0; i < 4; i++) 
    {
        static Func<int> getI(int i) => () => i;    // вспомогательная ф-ия для нового контекста
        funcs.Add(getI(i));
    }

    funcs.ForEach(f => Console.WriteLine(f()));

Используется тот трюк, что в мутабельных языках аргументы ф-ии замыкаются byval, в отличие от локальных переменных, которые замыкаются byref.

Это ж стандартная головная боль JS — регулярная необходимость преобразования захвата переменных byref в byval.
Забавно порой почитывать JS-программистов, которые даже спустя десяток лет опыта в JS в этом плавают.

C# тоже этой головной болью теперь наградили, но хоть компилятор ворнинги выдаёт, если прошляпишь.
А в JS "можно всё" (С).

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


V>>Но статические локальные ф-ии чисты относительно контекста, т.е. не подменяют значений и ссылок локальных переменных.
S>Правильный ответ — локальные функции настолько редко используются в делегатах и выражениях, что всем просто наплевать.

А откуда ты взял про "редко", не поделишься источником статистики? ))

Это просто новая фича, а чуть не весь используемый сейчас в дотнете код был написан до её появления.

А взять наши внутренние либы, писанные специально для .Net Core — это относительно новый код (в среднем пару лет ему), и там все новые фичи используются в полный рост.
И по-факту никакого "редко".

Меня раньше останавливала "тяжесть" локальных ф-ий, если де-факто контекст метода не использовался, но с вводом статических локальных ф-ий последний раздражающий фактор был преодолён.

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

А ты такой пишешь "никому не надо". ))
Как не вспомнить классику: "Слишком далеки они от народа!" (С) А.И.Герцен.

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

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

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

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

И поэтому делегаты такие дорогие в создании и вызове.


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

Да нет там никаких юридических дебрей, вот в чём странность.
Т.е. иск юридически ничтожен.

Поэтому, в кач-ве аргументов были не юридические доводы, а "общечеловеческие", филосовские и прочий такой бред.

Это почему суды присяжных, таки, фуфел, судопроизводством должны заниматься профессионалы.

Смотри, вот ты однажды утром проснулся, взял, допустим, открытый стандарт С++, который не покрыт ни патентами, ни запретами на клонирование, ни чем бы то ни было еще.
Вот ты "форкнул" стандарт для себя, добавил нужных тебе фич, назвал С+++, написал компилятор, показал людям.

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

Есть изнанка капитализма: деньги (в т.ч. интересы инвесторов и прочее) превыше закона.


S>Возможно, мы сейчас бы жили в мире, где дотнета нет, зато есть java с value-типами и нормальными генериками, а не этой порнографией.

Не факт, достаточно посмотреть на веб.

MS вставляли палки в колеса в течении 15 лет, не давали развивать веб.
Почему? — потому что сами отставали.

MS на веб забила в итоге, бо и так IE в течении 15 лет был лучше любых альтернатив.

А потом эти отстающие с грехом пополам допилили эппловский WebKit до более-менее вменяемого состояния, выкатили Хром.
Сказали: "Вот теперь мы тоже готовы развивать веб, так давайте же его развивать!"

Но 15 лет потеряно.
Так же было бы и с джавой — это были бы такие же точно гири на ногах.

Т.е., в IT индустрии в плане стандартов происходит равнение на отстающих.
А вылезающих вперёд враждебное к друг другу до этого стадо объединившись совместно мочит выскочку, прямо как в старом советском мультике:
https://www.youtube.com/watch?v=phl_hFPBY0U


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

Имели бы одну платформу, отстающую в развитии от имеющихся сегодня лет на 15. ))

А так дотнет мог делать что хотел...
Ну и Джава ойкнула от неожиданости и тоже начала шевелиться.


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

У нас это одни и те же люди.


S>То есть анонимную локальную функцию — можно, безо всяких ворнингов, а именованную — уже нельзя.

На новый круг заход? ))
Вычислительное выражение C# чисто, но блок кода — не факт.
Поэтому блоки нельзя.


S>То есть в делегате ссылаться на потенциально нечистую функцию — ок

Отродясь.


S>а в expression — уже зашквар?

Я так думаю, что из тех соображений, мол, а как нечистую ф-ию переводить в SQL?

Но ограничение всё-равно странное, бо использованный в чистой ф-ии делегат тоже в SQL не уедет, т.е. expression-to-DB провайдер ругнётся в рантайме.
Т.е., можно было бы во всех случаях выбрасывать рантайм-ошибки, в т.ч. и для выражений-блоков, если нет возможности перевести их в SQL.


V>>А как обеспечить чистоту функций на уровне языка — непонятно.
S>Это опять рационализация иррационального.

ИМХО, это еще один инструмент проектирования.

Есть же языки, которые позволяют помечать нужные ф-ии как чистые.
В таких ф-иях нельзя производить нечистые вычисления, компилятор не скомпилит.

Причём, это удобней чистых ФП-языков, т.к. ф-ия запросто может быть чистой даже если использует мутабельные переменные в своём теле.


V>>Про локальные я полностью согласен — это непредсказуемая дичь в случае Expression и обычных делегатов, т.к. не всегда очевидно, что именно захватывается и где, т.к. таких локальных ф-ий может быть несколько, но они шарят общий контекст.
S>Как видим, в случае делегатов это никому не мешает.

Откуда "мы" это видим, если у тебя проявляется та же ошибка, только теперь без ворнинга? ))

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

    var funcs = new List<Func<int>>();

    for(int i = 0; i < 4; i++) 
    {
        static Func<int> getI(int i) => () => i;    // вспомогательная ф-ия для нового контекста
        funcs.Add(getI(i));
    }

    funcs.ForEach(f => Console.WriteLine(f()));

Используется тот трюк, что в мутабельных языках аргументы ф-ии замыкаются byval, в отличие от локальных переменных, которые замыкаются byref.

Это ж стандартная головная боль JS — регулярная необходимость преобразования захвата переменных byref в byval.
Забавно порой почитывать JS-программистов, которые даже спустя десяток лет опыта в JS в этом плавают.

C# тоже этой головной болью теперь наградили, но хоть компилятор ворнинги выдаёт, если прошляпишь.
А в JS "можно всё" (С).

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


V>>Но статические локальные ф-ии чисты относительно контекста, т.е. не подменяют значений и ссылок локальных переменных.
S>Правильный ответ — локальные функции настолько редко используются в делегатах и выражениях, что всем просто наплевать.

А откуда ты взял про "редко", не поделишься источником статистики? ))

Это просто новая фича, а чуть не весь используемый сейчас в дотнете код был написан до её появления.

А взять наши внутренние либы, писанные специально для .Net Core — это относительно новый код (в среднем пару лет ему), и там все новые фичи используются в полный рост.
И по-факту никакого "редко".

Меня раньше останавливала "тяжесть" локальных ф-ий, если де-факто контекст метода не использовался, но с вводом статических локальных ф-ий последний раздражающий фактор был преодолён.

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

А ты такой пишешь "никому не надо". ))
Как не вспомнить классику: "Слишком далеки они от народа!" (С) А.И.Герцен.