S>int x = Root.?Config.?User.?Age;
S>

int? x = Root.?Config.?User.?Age;

int? x;
if (Root != null && Root.Config != null && Root.Config.User != null)
    x = Root.Config.User.Age;
else
    x = null;

int? a;
a = null;
Console.WriteLine(a > 1);
a = 1;
Console.WriteLine(a > 1);
a = 2;
Console.WriteLine(a > 1);

False
False
True

int age;
try {  age = Root.Config.User.Age;} 
catch (NullReferenceException)  {age=0;}
if (age > 16)
{
  bla-bla
|

Кё>Нет, оператор не дожен возвращать никакой тип, иначе ничего не выйдет Именно это мне и показалось интересным — не простое вычисление выражения в операторе if по правилам языка, а какое-то более сложное поведение, в данном случае — считать само условие невыполненным в случае невозможности вычислить аргументы.

nil возвращаемый из методов в Objective-C /.../ в ответ на посылаемое ему сообщение nil не бросает исключение, а попросту игнорирует это сообщение. То есть, nil из Objective-C ведёт себя как "черная дыра". Это пустота. Это ничто. При посылке к nil-у любого сообщения, всё что вы получите назад — это nil. Не будет никаких исключений, никаких возвращенных значений. Ничего.
/.../
поведение ``поедающее'' сообщения позволяет создавать более элегантный код!
/.../
Предположим, что мы хотим найти последний телефонный номер, который вы набрали со своего офисного телефона, и сохранить этот номер в переменной, скажем, 'последнийНомер'. Далее предположим, что мы хотим сохранить этот номер как строку и затем отобразить его в виджете (или же использовать этот номер позже). Если вы -- это 'человек' в последовательности сообщений приведённой далее, то достаточно ли этой последовательности для получения работоспособной программы?

    последнийНомер := человек офис телефон последнийИсходящийНомер какСтрока.
    виджет строковоеЗначение: последнийНомер.

Возможно.

Но что, если у человека нет офиса? Или в офисе нет телефона? Или что если это новый телефон и по нему еще никто не звонил? В любом из этих случаев, при использовании ``исключенческого'' nil-а будет выброшено исключение, которое приведёт к остановке программы, если только не будет создан соответствующий обработчик исключения.

А что с nil-ом ``поедающим'' сообщения? В этом случае 'последнийНомер' может в качестве значения принять nil, но всё будет работать и в этом случае. Даже передача nil-а как аргумента для метода #строковоеЗначение:1будет работать, потому что ``поедающий'' nil может нормально работать с виджетами. Совершенно не важно, что аргумент это nil. Всё будет работать без бросания исключений и без заметных с первого взгляда побочных эффектов (на этом подробнее остановимся позже).

Для сравнения, ниже приведён код для работы с ``исключенческим'' nil-ом:

    | врем |
  врем := человек офис.
  врем неПусто еслиИстина: [врем := врем телефон].
    врем неПусто еслиИстина: [врем := врем последнийИсходящийНомер].
    врем неПусто еслиИстина: [врем := врем какСтрока].
    виджет строковоеЗначение: последнийНомер.

DG>if (Root.Config.User.Age > 16)
DG>{
DG>   //bla-bla
DG>}
DG>

class A
{
    public A(int i) { I = i; }
    public int I;
    public static readonly A Default = new A(-1);
}

class B
{
    public B() { A = A.Default; }
    public B(A a) { A = a; }
    public A A;
    public static readonly B Default = new B();
}

class Program
{
    static void Main()
    {
        B b = new B();

        int i = b.A.I;
    }
}