Меня часто спрашивают «парни, вы добавили методы расширения в C# 3, так почему бы не добавить ещё и свойства расширения?»

Хороший вопрос.

Давайте, сначала я чуть поговорю о C# 3.0. Явно главной новостью в C# 3 был LINQ. В некотором смысле, у нас было всего три новых возможности в C# 3:

• всё необходимое для LINQ – неявно типизированные переменные, анонимные типы, лямбда-выражения, методы расширения, инициализаторы объектов и коллекций, конструкторы запросов, деревья выражений, улучшенный вывод типов
• частичные методы
• автоматически реализуемые свойства

Последние два были крошечными по сравнению с пунктами из первой пачки. С точки зрения проектирования, синтаксис и семантика обеих возможностей прямолинейны. С точки зрения реализации, у нас уже были механизмы для устранения вызовов; частичные методы и условные методы – почти одно и то же за кулисами. Авто-свойства также были весьма прямолинейны в анализе и генерации кода. Нагрузка по тестировнию тоже была для них не особенно большой.

Команда C# была «длинным шестом» в 2008 релизе Visual Studio и .NET Framework. Под этим я имею в виду то, что если бы вы взяли количество времени, нужно для выполнения работы, на которую подписалась каждая команда, с учётом численности персонала, всё такое, и сделали шесты пропорциональной этому длины для каждой команды в Developer Division, то шест C# оказался бы самым длинным. Что означает, что у любой другой команды в DevDiv был запас в расписании, но если бы мы отстали на день от своего расписания, то новая студия и CLR тоже были бы выпущены на день позже. Если бы любая другая команда отстала на день, ну, до тех пор, пока это не делало их шест длиннее нашего, у них всё ещё было бы всё в порядке. Внутри нашей команды, при разделе работы между разными её участниками, «длинным шестом» были задачи привязывания лямбд и вывода типов методов, отданные мне. Так что, в некотором смысле, каждый день моего опоздания одначал запаздывание выхода продукта на столько же дней. (Никакого давления!)

К счастью, у нас тут превосходная команда, мы все очень хорошо помогали друг другу в течение этого релиза, подхватывая задачи друг друга при необходимости, и выполнили качественный релиз за долгое время. Моя мысль – в том, что если что-то не было либо необходимым для LINQ, либо маленьким, ортогональным, и легковыбрасываемым в случае необходимости (как остальные две), это выбрасывали немедленно. Ни в коем случае мы не собирались рисковать задержать выход всего продукта для какой-то штуки, которая была бы сразу и сложной и не необходимой. Конечно же, сразу было очевидно, что естественным спутником методов расширения являются свойства расширения. Менее очевидно, по какой-то причине, что события расширения, операторы расширения, конструкторы расширения (также известные, как «паттерн «фабрика»»), и так далее, тоже являются естественными спутниками. Но мы даже не рассматривали вопрос проектирования свойств расширения в C# 3; мы знали, что без них можно обойтись, и они добавят риск в и итак уже рискованное расписание, без привлекательного выигрыша.

Ну, теперь мы дошли до C# 4.

Как я люблю напоминать, ответ на все вопросы вида «почему в продукте X нет возможности Y?» один. Этопотому, что для того, чтобы в продукте была некоторая возможность, эта возможность должна быть

• в первую очередь продумана
• нужна
• спроектирована
• специфицирована
• реализована
• протестирована
• задокументирована
• доставлена потребителям

Мы должны пройти каждый из этих пунктов, иначе – никаких новшеств.

Когда мы начали работать над C# 4, мы составили список всех запросов, о которых мы только слышали. В нём были сотни возможностей. Как я описывал в прошлом году, мы рассортировали тот список по корзинкам «стоит сделать / неплохо бы / плохая идея». Свойства расширения были в корзинке «стоит сделать». Затем мы посмотрели на доступный нам бюджет – который измерялся не столько в долларах, сколько в доступных проектировщиках, разработчиках, тестерах, писателях, и менеджерах, умноженных на доступное время – и определили, что у нас хватит ресурсов на реализацию примерно половины вещей в корзинке «стоит сделать». Так что мы выбросили половину этого. Свойства расширения пережили это урезание. Затем мы спроектировали эту возможность. У нас были многочасовые споры о предполагаемом синтаксисе деклараций, способах «прямого» вызова методов чтения и записи как статических методов, и так далее. Мы придумали и согласовали приемлемый синтаксис, спроектировали семантику, написали черновик спецификации, и начали писать код и планы тестирования.

К моменту, когда код дошёл до приличного состояния – еще не до конца протестирован, но работает и соответствует спецификации – мы стали устраивать собрания с командой WPF. Разработчики WPF были предполагаемыми основными потребителями свойств расширения. В WPF уже есть механизм, похожий на свойства расширения; было бы неплохо унифицировать этот механизм с нашим. К сожалению, рассмотрев хорошенько их реальные сценарии, мы прили к разочаровывающему выводу о том, что мы спроектировали не то; эта возможность на самом деле не решала их проблемы. Это, надо признать, провал процесса проектирования. Мы должны были поинтересоваться мнением основного потребителя намного раньше. Сделай мы это – и они могли бы либо повлиять на дизайн и получить что-то, пригодное для них, или бы мы выбросили эту возможность из плана без затрат на написание спецификации, кода, и планов тестирования.

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

Так что, к сожалению, никаких свойств расширения в C# 4. Возможно, в гипотетической будущей версии C#.

Вот любопытный фрагмент кода:

object obj = "Int32";
string str1 = "Int32";
string str2 = typeof(int).Name;
Console.WriteLine(obj == str1); // true
Console.WriteLine(str1 == str2); // true
Console.WriteLine(obj == str2); // false !?

Конечно, если A равно B, и B равно C, то A равно C, это транзитивное своейство равенства. Похоже, что оно тут полностью нарушено.

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

Во-вторых, здесь происходит смешение двух разных видов равенства, которые случайно используют одинаковый синтаксис операторов. Мы смешиваем равенство по ссылке с равенством по значению. Объекты сравнивают по ссылке; в первом и третьем сравнении мы проверяем, что обе ссылыки указывают в точности на один и тот же объект. Во втором сравнении мы проверяем, одинаково ли содержимое двух строк, вне зависимости от того, представлены ли они одним объектом. Фактически, компилятор предупреждает вас о такой ситуации; такой код должен порождать предупреждение «возможно непреднамеренное сравнение ссылок».

Это может потребовать чуть больше объяснений. В .NET вы можете иметь две строки с идентичным содержимым, но они будут разными объектами. Когда вы сравниваете эти строки как строки, они равны, но когда вы сравниваете их как объекты, они не равны.

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

Это результат маленькой оптимизации. Если у вас есть два идентичных строковых литерала в одной единице компиляции, то код, который мы генерируем, гарантирует, что только один объект строки создаётся CLR для всех экземпляров этого литерала в пределах сборки. Эта оптимизация называется «интернированием строк».

String.Empty – не константа, это поле только-для-чтения в другой сборке. Поэтому оно не интернируется с пустой строкой в вашей сборке; это два разных объекта.

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

Зная это, вы теперь можете сделать обоснованное предположение причины, по которой мы имеем это противоестественное поведение:

object obj = "";
string str1 = "";
string str2 = String.Empty;
Console.WriteLine(obj == str1); // true
Console.WriteLine(str1 == str2); // true
Console.WriteLine(obj == str2); // иногда true, иногда false?!

Некоторые версии .NET автоматически интернируют пустую строку, некоторые – нет!

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

Ответ – в том, что принцип ЛДНБ применим здесь в полной мере. То есть, Ланчей Даром Не Бывает. Интернирование имеет два положительных эффекта: оно уменьшает потребление памяти и уменьшает время сравнения двух строк. (Потому, что если все строки интернируются во время выполнения, то все сравнения строк могут быть дешёвыми сравнениями ссылок.) Но у этих положительных эффектов есть цена: выделение новой строки теперь требует от вас поиска по всем строкам в памяти для проверки, нет ли там уже такой. В нашей существующей оптимизации, цена невелика; во время компиляции нам известно, каковы строковые литералы в данной сборке и какие из них одинаковы. В предлагаемой оптимизации, эта цена платится во время выполнения, и может занимать весьма большую долю затрат времени на выделение строк.

Чтобы снизить затраты времени, вам бы пришлось построить хеш-таблицу всех строк в памяти. Это означает либо частое вычисление хеш-кодов, что само по себе затратно по времени, либо их хранение где-то. Если мы выбираем последнее, то внезапно мы увеличиваем нагрузку на память для строк, которые не дублируются. То есть, наша оптимизация заставляет обычный сценарий – подавляющее большинство пар строк не совпадают друг с другом – требовать больше памяти, чтобы редкий сценарий мог её сэкономить. Это выглядит плохой сделкой; обычно вы хотите оптимизировать для более вероятного случая.

Кроме того, у интернированных строк есть также и серьёзные проблемы с временем жизни. Когда их можно безопасно подвергнуть сборке мусора? Что, если новая копия строки создаётся в тот момент, когда старую удаляет сборщик в другом потоке? Самое безопасное – сделать интернированные строки бессмертными, что выглядит как утечка памяти. Утечки памяти плохо влияют на производительность, особенно когда ваша оптимизация – это попытка сэкономить память. ЛДНБ!

Короче, в общем случае не стоит интернировать все строки. Тем не менее, это может оказаться стоящим в некоторых особых случаях. Например, если бы вы писали на C# компилятор, то вы бы скорее всего порождали в процессе выполнения большое количество одинаковых строк. Наш компилятор C# написан на C++, где мы написали нашу собственную прослойку интернирования строк, чтобы мы могли выполнять дешёвые ссылочные сравнения для всех строк в вашей программе. Весьма вероятно, что «int» будет встречаться десятки, сотни, или тысячи раз в одной программе; глупо выделять одну и ту же строку снова и снова. Если вы пишете на C# компилятор, или какое-то другое приложение, в котором вы чувствуете, что стоит постараться не дать тысячам идентичных строк потребить много памяти, то вы можете заставить среду исполнения интернировать вашу строку при помощи метода String.Intern.

И, наоборот, если вы ненавидите интернирование слепой ненавистью, то можете заставить среду отключить всё интернирование строк в сборке при помощи атрибута CompilationRelaxation.

В любом случае, вернёмся к вопросу транзитивности: равенство ссылок на объекты на самом деле транзитивно. Оно также симметрично (A==B подразумевает B==A) и рефлексивно (A==A), так что это отношение эквивалентности. Похожим образом, равенство значений строк транзитивно, симметрично и рефлексивно, поскольку оно использует прямолинейное сравнение «символ за символом». Но когда вы смешиваете их, то равенство перестаёт быть транзитивным. Это странно, но, надеюсь, теперь доступно для понимания.

Вот хороший вопрос со StackOverflow:

Если у вас есть метод, принимающий «X», то вы должны передавать выражение типа X или что-то, приводимое к X. Скажем, выражение производного от X типа. Но если у вас есть метод, принимающий «ref X», то вы обязаны передавать ссылку на переменную типа X, точка. Почему это? Почему бы не разрешить типу варьироваться, как мы делаем для не-ref вызовов?

Предположим, что у вас есть классы Животное, Млекопитающее, Рептилия, Жираф, Черепаха и Тигр, с очевидными отношениями наследования.

Теперь предположим, что у вас есть метод void M(ref Млекопитающее m). M может как читать, так и писать m. Можно ли передать в M переменную типа Животное? Нет. Это было бы небезопасно. Такая переменная может ссылаться на Черепаху, но M предполагает, что там могут быть только Млекопитающие. Черепаха – не млекопитающее.

Вывод 1: Ref-параметры нельзя делать «больше». (Животных больше, чем млекопитающих, так что переменная становится «больше» потому, что в неё входит больше разных существ)

Можно ли передать в M переменную типа Жираф? Нет. M может записывать в m, и может захотеть записать туда экземпляр Тигра. Теперь вы засунули Тигра в переменную, которая имеет тип Жираф.

Вывод 2: Ref-параметры нельзя делать «меньше».

Теперь рассмотрим N(out Млекопитающее n).

Можно ли передать в N переменную типа Жираф? Нет. Как и в нашем предыдущем примере, N может записывать в n, и N может захотеть записать туда Тигра.

Вывод 3: Out-параметры нельзя делать «меньше».

Можно ли передать в N переменную типа Животное?

Хмм.

Ну, почему бы и нет? N не может читать из n, он может туда только писать, верно? Вы записываете Тигра в переменную типа Животное и всё в порядке, так?

Нет. Правило не в том, что «N может только записывать в n». Правила, вкратце, таковы:

1) N обязан записать в n перед тем, как выполнить нормальный возврат (если N бросает исключение, то с него взятки гладки)

2) N обязан записать что-то в n перед тем, как что-то оттуда прочитать.

Это позволяет такую последовательность событий:

• Объявляем поле x типа Животное.
• Передаём x как out-параметр в N
• N пишет Тигра в n, который является псевдонимом для x.
• В другом потоке, кто-то записывает в x Черепаху.
• N пытается читать содержимое n, и обнаруживает Черепаху в том, что, по его мнению, является переменной типа Млекопитающее.

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

UPDATE: Комментатор Павел Минаев верно подметил, что нет нужды в многопоточности для нанесения увечий. Мы можем заменить четвёртый шаг на

• N делает вызов метода, который прямо или косвенно заставляет некоторый код записать в x Черепаху.

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

Вывод 4: Out-параметры нельзя делать «больше».

Есть и другой аргумент в пользу этого вывода: «out» и «ref» на самом деле за кулисами совершенно одинаковы. CLR поддерживает только «ref»; «out» - это всего лишь «ref», для которого компилятор навязывает несколько другие правила насчёт того, когда рассматриваемая переменная подвергается определяющему присваиванию. Вот почему запрещено делать перегрузки метода, которые отличаются только out/ref-ностью параметров; CLR неспособен их различить! Так что правила типобезопасности для out вынуждены быть такими же, как и для ref.

Окончательный вывод: Ни ref ни out параметры не позволяют варьировать типы аргументов в местах вызова. Иное бы нарушило верифицируемую безопасность типов.

Так же, как «fixed» и «into», «partial» используется в С# двумя похожими-но-разными способами.

Задача частичного класса в том, чтобы позволить вам разбивать объявление класса на несколько частей, обычно расположенных в различных файлах. Мотиватором этой возможности был машинно-генерируемый код, который пользователю нужно было расширять путём прямых добавлений. Когда вы рисуете форму в дизайнере форм, дизайнер генерирует для вас класс, представляющий эту форму. Вы можете затем далее изменять этот класс, добавляя в него новый код. Если вы можете редактировать код, сгенерированный машиной, то возникает масса проблем. Что, если он будет сгенерирован повторно? Что, если машина использует сам код для хранения информации о дизайне формы, и ваши правки сбивают с толку парсер машины? Гораздо лучше просто поместить машинно-генерируемую половину в отдельный файл, сгенерировать комментарий «не трогайте это», и разместить пользовательский код в другом месте.

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

• Если класс действительно большой, и реализует пачку интерфейсов, то, иногда, реализация каждого интерфейса в отдельном файле имеет смысл. Хотя, чаще это признак плохого кода, присущий классу, который пытается делать слишком много всего; разделение этой штуки на несколько классов может оказаться лучше.
• Иногда приятно выносить вложенные классы в отдельные файлы; единственный приличный способ этого добиться – это сделать содержащий их класс частичным.
• И так далее

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

Способ, которым работают частичные методы – это наличие двух объявлений, «латентного», и «актуального». У латентного объявления нет тела, как будто это абстрактный метод. У актуального – есть. Латентное объявление располагается на машинно-сгенерированной стороне частичного класса, актуальное объявление попадает в часть, написанную человеком. Если у нас есть актуальное объявление, то латентное полностью игнорируется. Но если актуального объявления нет, то все вызовы метода устраняются, как будто он был скомпилирован с условным атрибутом! И, фактически, латентное объявление также устраняется в момент порождения метаданных для сгенерированного класса; как будто его и не было.

Причина для такого поведения – в том, что мы хотели сделать возможным такой сценарий:

// Машинно-генерируемый код:
partial class MyFoo
{
void ButtonClickEventHandler(/*всякое*/)
{
// вызвать пользовательский код чтобы посмотреть, не хочет ли он чего-нибудь сделать
OnBeforeButtonClick(всякое);
тра ля ля
// опять вызвать пользовательский код
OnAfterButtonClick(всякое);
}
partial void OnBeforeButtonClick(/*всякое*/);
partial void OnAfterButtonClick(/*всякое*/);
...

Пользователь будет модифицировать частичный класс; вставляя частичные методы, машинно-сгенерированная часть может повсеместно создать простые точки расширения, которые пользователь потом сможет реализовать. Но подумайте о негативных последствиях этого в мире без частичных методов. Пользователя заставляют реализовывать пустые методы. Если он этого не сделает, то получит ошибку. Потенциально там нужно реализовать сотни этих пустых методов, а это бесит. И каждый из этих методов генерирует нетривиальное количество метаданных, делая результирующую библиотеку больше, чем нужно. Дисковое пространство дёшево, но латентность сети заменила дисковое пространство в качестве фактора против больших сборок. Было бы здорово, если бы мы могли избавиться от этого груза метаданных.

Частичные методы удовлетворяют требованиям. Пользователь может предоставлять реализации для методов по собственному выбору, и это становится моделью с «платой за фактическое использование»; вы получаете столько расходов на реализацию, сколько методов вы реализуете.

Эта возможность во время процесса проектирования называлась «латентные и актуальные методы»; мы серьёзно рассматривали добавление новых ключевых слов «latent» и «actual». Но, поскольку эта возможность имеет смысл только в сценариях с частичными классами, то мы решили повторно использовать существующее контекстное ключевое слово «partial» и переименовали возможность. Надеюсь, что созвучие между двумя применениями «partial» помогает больше, чем тонкая разница вредит.

СУПЕР ЭКСТРА БОНУС: Ещё немного частичности

Мы рассматривали добавление третьего типа «частичности» в C# 4.0; эта возможность прошла через фазу проектирования, но была выброшена до реализации. (Если будет высокий спрос, то мы рассмотрим добавление её в гипотетических будущих версиях C#.)

Иногда вы участвуете в сценарии машинной генерации кода типа такого:

// сгенерировано машиной
partial class C
{
int blah;
...

И затем на той стороне, которую генерирует пользователь, вы хотите сделать что-то вроде:

// User generated
partial class C : ISerializable
{

И, о, чёрт, мне нужно пометить blah атрибутом NotSerialized, но я не могу редактировать текст blah потому, что когда его перегенерируют, это всё пропадёт.

Идея этого нового типа частичности – в том, чтобы повторять объявление члена – поля, метода, вложенного типа, чего угодно – с атрибутами метаданных. Это как латентные/актуальные методы, только наоборот; «актуальная» часть – на машинно-генерируемой стороне, а «латентная» часть на стороне, генерируемой пользователем, нужна только для добавления метаданных:

[NotSerialized] partial int blah; // на самом деле не объявляет поле

Мне нравится такая возможность, но во время процесса проектирования я сопротивлялся, как мог, использованию ключевого слова «partial» в третьем значении, слегка отличающемся от первых двух. Добавление такой путаницы один раз казалось оправданным, но дважды? Это перевешивает. Так что мы сошлись на добавлении другого контекстного ключевого слова:

[NotSerialized] existing int blah; // на самом деле не объявляет поле

Оформление объявления при помощи «existing» значило бы «это не настоящее объявление, это упоминание существующего объявления; пожалуйста, проверьте, что такое объявление существует где-то еще в этом частичном классе, и добавьте эти метаданные к тому члену».

Как я сказал, эта полезная возможность была выброшена из-за ограниченности ресурсов. Если у вас есть реально обалденные сценарии, которые бы она облегчила, то я был бы счастлив о них услышать; очевидно, я не могу делать никаких обещаний о будущих возможностях необъявленных, полностью гипотетических продуктов. Но реальные пользовательские сценарии являются сильным мотивирующим фактором в выделении бюджета для новых возможностей.

Пользователь: почему эта программа отказывается компилироваться в релизном билде?

class Program
{
#if DEBUG
    static int testCounter = 0;
#endif
    static void Main(string[] args)
    {
        SomeTestMethod(testCounter++);
    }
    [Conditional("DEBUG")]
    static void SomeTestMethod(int t) { }
}

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

Пользователь: Но этот вызов всё равно будет выброшен, так почему это имеет значение? Явно есть какая-то разница между устранением кода при помощи условной компиляции и при помощи условного атрибута, но в чём эта разница?

Эрик: Тебе уже известен ответ на твой вопрос, просто ты об этом еще не знаешь. Давай поиграем в Сократа; я верну вопрос тебе – как это работает? Откуда компилятор узнает, что нужно устранить вызов метода?

Пользователь: Потому, что вызываемый метод помечен атрибутом Conditional.

Эрик: Это знаешь ты. Но откуда компилятор знает, что вызываемый метод помечен атрибутом Conditional?

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

Эрик: Ясно. То есть, фундаментально, основная работа делается разрешением перегрузок. А откуда разрешение перегрузок знает, что нужно выбрать именно тот метод? Предположим гипотетически, что у нас там был и другой метод с тем же именем и другими параметрами.

Пользователь: Разрешение перегрузок работает путём изучения аргументов вызова и сравнения их с типами параметров каждого метода-кандидата, и затем выбора единственного лучшего соответствия среди всех кандидатов.

Эрик: Вот и оно. Таким образом, аргументы должны быть полностью определены в точке вызова, даже если вызов будет впоследствии устранён. Фактически, вызов невозможно устранить, не имея в наличии аргументов! Но в релизном билде, тип аргумента невозможно определить, потому что его объявление было выброшено.

Так что теперь вы видите, что реальная разница между этими двумя техниками устранения нежелательного кода а том, что делает компилятор в момент устранения. На высоком уровне, компилятор обрабатывает текст так. Сначала он «лексит» файл. То есть, разбивает строку на «лексемы» - последовательности букв, цифр и символов, которые имеют смысл для компилятора. Затем эти лексемы «разбираются», чтобы проверить соответствие программы грамматике C#. Затем разобранное состояние анализируется для определения семантической информации о нём; каков тип каждого выражения и всё такое. И, наконец, компилятор выплёвывает код, который эту семантику реализует.

Действие директивы условной компиляции происходит во время лексического разбора; всё, что попало внутрь устранённого блока #if трактуется лексическим анализатором как комментарий. Как будто вы просто удалили всё содержимое блока и заменили пробелом. Но устранение вызовов в зависимости от условных атрибутов происходит во время сематического анализа; всё необходимое для проведения этого семантического анализа должно быть в наличии.

Пользователь: Потрясающе. Какие разделы спецификации C# определяют это поведение?

Эрик: Спецификация начинается с удобного «содержания», которое очень помогает в ответах на такие вопросы. Содержание утверждает, что секция 2.5.1 описывает «Символы условной компиляции», а секция 17.4.1. описывает «атрибут Conditional».

Пользователь: Обалдеть.

Ключевое слово «into» в выражениях-запросах означает две разных вещи, в зависимости от того, идёт ли оно после join или select/group. Если оно следует за join, то оно превращает объединение в групповое объединение. Если оно следует за select или group, то оно вводит продолжение запроса. Эти две вещи сильно отличаются, но их легко спутать.

Во-первых, групповое объединение. Предположим, у вас есть ключ – идентификатор покупателя – который используется в качестве первичного ключа коллекции покупателей, и в качестве внешнего ключа в коллекции номеров кредитных карточек. То есть, у вас есть класс Customer с полями Id, Name, Address, и так далее, и класс CreditCard с полями CustomerId, CardType, Number, и так далее. Пусть у покупателя Боба есть Виза и Дискавер, а у покупателя Алисы есть Виза и Мастеркард. Так что у нас есть данные о покупателях:

101, Bob
102, Alice

и данные кредиток:

101, Visa
101, Discover
102, Visa
102, MasterCard

Если мы построим запрос

from customer in customers
join card in cards on customer.Id equals card.CustomerId
select new {customer.Name, card.Kind}

То результатом будет

Bob, Visa
Bob, Discover
Alice, Visa
Alice, Mastercard

Верно? Это всего лишь прямолинейное объединение. Мы заканчиваем списком из четырёх элементов. Но это, вероятно, не то, что вы на самом деле хотите в этом случае. Предположим, что вы хотели список покупателей, и для каждого покупателя в списке, список их кредиток. Вы можете использовать групповое объединение:

from customer in customers
join card in cards on customer.Id equals card.CustomerId into cardList
select new {customer.Name, Cards = cardList}

Результатом этого запроса были бы две записи, а не четыре:

Bob, { Visa, Discover }
Alice, { Visa, Mastercard }

В основном, «into» в групповом объединении – это порция выражения-запроса, которая логически собирает результаты всех объединённых записей, объединяет их в последовательность, и запихивает их во временную переменную cardList.

Продолжение запроса означает совсем другое. Смысл продолжения запроса в упрощении «передачи» результатов одного запроса в следующий запрос. Например, предположим, что вы хотите найти всех кареглазых детей, у кого есть хотя бы один голубоглазый брат или сестра. Очевидный способ сделать это – что-то вроде

from parent in parents
from child in parent.Children
where child.EyeColor == "Brown"
where parent.Children.Any(c=>c.EyeColor == Blue)
select child

но предположим, что мы не хотим так делать. Предположим, что там много больших семей, где все дети с карими глазами; наивный поиск будет довольно-таки неэффективным. Вы можете захотеть сначала сузить его другим способом. То есть, возможно, было бы быстрее сначала найти всех родителей, у кого есть голубоглазый ребёнок, а затем из этого короткого списка родителей извлечь всех кареглазых детей. Проще всего это сделать двумя запросами. Сначала найти родителей, а затем из этого построить второй запрос с проекцией детей:

var parentsWithABlueEyedChild =
    from parent in parents
    where parent.Children.Any(c=>c.EyeColor == Blue)
    select parent;
var brownEyedChildren =
    from p in parentsWithABlueEyedChild
    from child in p.Children
    where child.EyeColor == Brown
    select child;

Теперь мы можем достаточно легко скомбинировать это в один большой запрос:

var brownEyedChildren =
    from p in (
        from parent in parents
        where parent.Children.Any(c=>c.EyeColor == Blue)
        select parent)
    from child in p.Children
    where child.EyeColor == Brown
    select child;

Но... Представьте чуть больше уровней вложенности. Это превратится в бардак. Заметьте, как мы ввели переменную диапазона «p» вначале, а потом нам пришлось пробраться через весь второй запрос прежде, чем снова её употребить. Здесь мы вводим переменные в «обратном» порядке. Продолжение запроса просто позволяет вам изменить этот порядок обратно на «прямой», перемещая переменную диапазона p в конец первоначального запроса:

var brownEyedChildren =
    from parent in parents
    where parent.Children.Any(c=>c.EyeColor == Blue)
    select parent into p
    from child in p.Children
    where child.EyeColor == Brown
    select child;

Заметьте, что в случае группового объединения, можно считать идентификатор справа от «into» логически представляющим последовательность, полученную в результате группировки соответствующих присоединённых элементов. Но в случае продолжения запроса, «into»-идентификатор не соответствует последовательности из первого запроса – сам запрос и есть объект, представляющий первую последовательность! Вместо этого, «p» представляет переменную диапазона, которая соответствует одному элементу коллекции за раз. Помните, «into» в продолжении запроса – всего лишь модный способ сказать from p in (blah); «p» - это переменная диапазона, которая по очереди проходит элементы (blah), но не сама последовательность элементов (blah).

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

Почему мы не разрешаем анонимные итераторы? Я был бы счастлив иметь анонимные блоки итераторов. Я хочу писать что-то вроде:

IEnumerable<int> twoints = ()=>{ yield return x; yield return x*10; };
foreach(int i in twoints) ...

Было бы вообще офигенно уметь построить себе маленький генератор последовательностей на месте, замыкая в нём локальные переменные. Причина отказа проста: преимущества не перевешивают затраты. Офигительность изготовления генераторов последовательностей прямо на месте на самом деле относительно мала в большой картине мира, и в большинстве сценариев именованные методы делают эту работу достаточно хорошо. Так что преимущества не так уж неотразимы.

Затраты велики. Переписывание итераторов – это самое сложное преобразование в компиляторе, а переписывание анонимных методов – второе по сложности. Анонимные методы могут быть вложены в другие анонимные методы, и анонимные методы могут быть внутри блоков итераторов. Так что, первое что мы делаем, это переписываем все анонимные методы так, чтобы они стали методами класса-замыкания. Это предпоследнее, что делает компилятор перед генерацией IL для метода. Как только этот шаг выполнен, переписчик итераторов может предполагать, что в блоке итератора нет анонимных методов; все они уже были переписаны. Так что переписчик итераторов может сконцентрироваться на переписывании итератора, не беспокоясь о том, что там могли остаться нереализованные анонимные методы.

Кроме того, блоки итераторов никогда не вкладываются друг в друга, в отличие от анонимных методов. Переписчик итераторов может предполагать, что все блоки итераторов находятся «на верхнем уровне».

Если позволить анонимным методам включать блоки итераторов, то оба этих предположения можно выкинуть в окно. У вас может быть блок итератора, который содержит анонимный метод, который содержит анонимный метод, который содержит блок итератора, который содержит анонимный метод, и… буээ. Теперь нам нужно написать проход переписывания, который может обрабатывать вложенные блоки итераторов и вложенные анонимные методы одновременно, объединив наши два самых запутанных алгоритма в один намного более запутанный алгоритм. Это было бы реально трудно спроектировать, реализовать, и протестировать. Я уверен, мы достаточно умны для этого. У нас тут сообразительная команда. Но мы не хотим брать на себя этот тяжкий труд ради «полезной, но не необходимой» возможности.

оригинал статьи