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

B>>var b = new B { P2 = P1 + P };// ошибка прокладки между стулом и монитором!
B>>...и..... ннна тебе поддых канпелятором!! В object initializer ни мембера P, ни P1 канпелятор НЕ ВИДИТ!

S>Всё верно. Initializer исполняется в том же скоупе, где и new statement.

Это "объяснение" никак не объясняет, почему тогда виден P2!
Кроме того, OI — это вам не "скобочки для if" — это специфическая часть, которая работает (у MS) только после new.

Итак, ваше очко переходит зрителям, а вопрос так и остаётся неотвеченным. Перефразирую:

А накой ляд тогда делать вообще OI, если он такой кривой???
Вопрос-уточнение: мне не интересно, что думал Хлипперт и как конкретно он реализовал эту багофичу. С инженерной точки зрения что мешает видеть P1 и P?


B>>Я-то (наивный) думал, что {} — это просто сокращение для b.P2 = b.P1 + b.P ! Похоже, мелкомягкие что-то там намудрили под капотом.
S>Да, совершенно верно — баг в вашей логике. {} — это просто сокращение для b.P2 = P1 + P . Откуда вы там взяли справа префиксы b. — никакой логике не поддаётся.

Чушь полная. См. вопрос-уточнение выше.


B>>PS
B>>А я ведь ещё на заре этой дебильной фичи предлагал: не надо этой узколобой привязки инициализатора к конструктору!!
B>>Здесь j во-первых может инициализироваться в ЛЮБОМ месте кода, а во-вторых, чётко видно кто и откуда берётся: ".p1" — это внутренний мембер (потому что с точки),
B>> "p2" — мембер из объемлющего контекста. Просто и универсально как лом. Что помешало неумытым "синьорам" с индийских пальм сделать это по-человечески?

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

Наверное, может надо ПОДУМАТЬ и реализовать? Я сейчас не могу спонталыку просто взять и углубиться в тему компиляторостроения, но если вы приведёте пример такого вот "не очень понятно", то можно поговорить хотя бы о часностях.
Опережающий ответ:
1. Никто не сказал, что можно будет делать вложенные иниты. В конце концов, 99.999999% кода — это как раз простые донельзя конструкции одного уровня.
2. Если они будут вложенные и как-то конфликтовать, ВСЕГДА можно посидеть и придумать какое-то интересное решение.

Главное — БАЗОВАЯ ЛОГИКА должна быть инженерная, а не "у нас тут индусокод и вот так исторически сложилось".

В конце концов, для чего вообще придумывать фичи, кроме как для УДОБСТВА ПРОГРАММИСТА? И на поверку оказалось, что OI-сахарок — чёрте что и полностью обламывает прямую логику разработчика.