Интересная дискуссия про ассоциативность операции "?." в C#: https://roslyn.codeplex.com/discussions/543895
В Nemerle она лево-асссоциатвна, а в C# похоже будет право-асссоциатвной.

Одна из причин это упрощение кода, чтобы не писать каждый раз "?." и уменьшить количество проверок.

Nemerle:
a?.b().c() --> (a?.b()).c() --> (if(a != null) a else null).b().c()
a?.b()?.c() --> (a?.b())?.c() --> { def tmp = if(a != null) a.b() else null; if(tmp != null) tmp.c()) else null }


C#
a?.b().c() --> a?.(b().c()) --> if(a != null) a.b().c() else null

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

_NN>Nemerle:
_NN>a?.b().c() --> (a?.b()).c() --> (if(a != null) a else null).b().c()
не рабочая конструкция
если a==null -> error

Здравствуйте, Аноним, Вы писали:

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

_NN>>Nemerle:
_NN>>a?.b().c() --> (a?.b()).c() --> (if(a != null) a else null).b().c()
А>не рабочая конструкция
А>если a==null -> error

Об этом и говорят в обсуждении

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

_NN>Здравствуйте, Аноним, Вы писали:

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

_NN>>>Nemerle:
_NN>>>a?.b().c() --> (a?.b()).c() --> (if(a != null) a else null).b().c()
А>>не рабочая конструкция
А>>если a==null -> error

_NN>Об этом и говорят в обсуждении

Но более сложна конструкция уже рабочая.
Точно написал?

Здравствуйте, Аноним, Вы писали:

А>Но более сложна конструкция уже рабочая.
А>Точно написал?

Более сложная вида a?.b()?.c() да.
Однако тут получается две проверки вместо одной.

Мне кажется право-ассоциативность нужна более часто.
Может и в Nemerle стоит так сделать.

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

_NN>Мне кажется право-ассоциативность нужна более часто.
_NN>Может и в Nemerle стоит так сделать.

Ты сначала приведи внятный пример демонстрирующий хотя бы какое-то преимущество, а потом поговорим.

Ассоциативность у "?." такая же как у ".", чтобы они вместе нормально компоновались в выражение. Ну, и чтобы людей не удивлять.

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

_NN>Одна из причин это упрощение кода, чтобы не писать каждый раз "?." и уменьшить количество проверок.

_NN>C#
_NN>a?.b().c() --> a?.(b().c()) --> if(a != null) a.b().c() else null

Чушь какая-то. Ассоциативность имеет смысл когда один и тот же оператор применяется более одного раза. В твоем примере "?." одни. Ассоциативность в нем просто ни на что не действует.

Правая ассоциативность означает, что выражение:
a?.b?.c?.d будет интерпретировано как a?.(b?.(c?.d)), а не как ((a?.b)?.c)?.d.

Я даже не представляю как интерпретировать правоассоцитивный вариант.

Ты явно путаешь понятия.

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

VD>Ты сначала приведи внятный пример демонстрирующий хотя бы какое-то преимущество, а потом поговорим.
Ну вот пример из обсуждения рослина:

string ReturnStringOrNull() { .. }

var x = ReturnStringOrNull()?.Trim().Substring(1,2).Replace("a","b");

Методы String не возвращают null, поэтому можно обойтись одной проверкой, а не каждый раз.
Т.е. писать множество ?. не нужно будет.

VD>Ассоциативность у "?." такая же как у ".", чтобы они вместе нормально компоновались в выражение. Ну, и чтобы людей не удивлять.
Вот и у них обсуждение, что вроде логично считать все слева направо, а можно и сэкономить количество проверок.

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

_NN>Ну вот пример из обсуждения рослина:

_NN>

_NN>string ReturnStringOrNull() { .. }

_NN>var x = ReturnStringOrNull()?.Trim().Substring(1,2).Replace("a","b");
_NN>

Где тут второй "?.". Я же кажется рядом уже говорил, что ассоциативность возникает только когда операторов больше двух. В противном случае речь идет о приоритете.

Короче, разберись в терминах и переформулируй вопрос.

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

VD>Где тут второй "?.". Я же кажется рядом уже говорил, что ассоциативность возникает только когда операторов больше двух. В противном случае речь идет о приоритете.
Ну да, в данном случае речь о приоритете, я запутался

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

в качестве варианта избавления от проблем с ассоциативностью возвращать в оператор список

a+b+c

+[a,b,c]

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

a+(b+c)

+[a,+[b,c]]

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

_NN>Ну да, в данном случае речь о приоритете, я запутался

Ну, а что людей путаешь заголовком темы.

В Немерле, приоритеты у "?." и "." несколько различаются:

[assembly: OperatorAttribute("Nemerle.Core", "?.",    false, 285, 285)]
[assembly: OperatorAttribute("Nemerle.Core", ".",     false, 285, 301)]

Так, что возможно то что ты хочешь и так реализовано.

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

_NN>Интересная дискуссия про ассоциативность операции "?." в C#: https://roslyn.codeplex.com/discussions/543895
_NN>В Nemerle она лево-асссоциатвна, а в C# похоже будет право-асссоциатвной.

Тут надо развеять некоторые мифы. Это не вопрос ассоциативности, и в Roslyn отсутствует оператор ?.. В Roslyn есть бинарный оператор ?, который вычисляет свой левый операнд, и если он не null, то вычисляет правый операнд. Правый операнд может (и должен) начинаться на токены . или [, которые парсятся, соответственно, как начало member access или element access, в которых отсутствует явный левый операнд (здесь можно усмотреть синтаксическую аналогию с выражениями .Foo в VB внутри With блоков). В рантайме (и в compile-time с целью проверки типов) в качестве отсутствующего операнда подставляется значение левого операнда innermost enclosing бинарного оператора ?.

Если бы не дополнительное требование (существующее исключительно для упрощения данной конструкции), что токены . или [ должны следовать непосредственно за токеном ?, то выражение a ? .b.c(d()).e можно было бы записать как a ? (((.b).c(d())).e).

Бинарный оператор ? является лево-ассоциативным.

Окончательная версия спецификации, возможно, будет давать объяснение в несколько других терминах, но с точки зрения наблюдаемого поведения компилятора, оно будет в точности соответствовать тому, что я написал (по крайней мере, таковы текущие планы). Синтаксические деревья, которые выдаёт Roslyn API, соответствуют тому, что я написал.

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

N>в Roslyn отсутствует оператор ?.. В Roslyn есть бинарный оператор ?

О, как? И как разруливается неоднозначность с тернарным оператором?

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

N>>в Roslyn отсутствует оператор ?.. В Roslyn есть бинарный оператор ?

VD>О, как? И как разруливается неоднозначность с тернарным оператором?

Если следующий токен . или [, то это бинарный оператор, иначе — тернарный.

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

N>В Roslyn есть бинарный оператор ?, который вычисляет свой левый операнд, и если он не null, то вычисляет правый операнд. Правый операнд может (и должен) начинаться на токены . или [, которые парсятся, соответственно, как начало member access или element access
N>...Если бы не дополнительное требование (существующее исключительно для упрощения данной конструкции), что токены . или [ должны следовать непосредственно за токеном ?, то выражение a ? .b.c(d()).e можно было бы записать как a ? (((.b).c(d())).e).

Ну, тогда это ничем не отличается от операторов "?." и "?[". Только можно пробелы вставить в середину.

N>Бинарный оператор ? является лево-ассоциативным.

В немерле мы "?[" не реализовывали. Как-то на практике не требовалось.

Я только не понял, что NN хочет.

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

VD>Я только не понял, что NN хочет.

Я так понял, что он интересуется, что означает выражение a?.b.c в Nemerle.
Или же это (a?.b).c (что может бросить NRE, если (a?.b) даёт null), или оно имеет смысл a ? («значение-a-если-не-null».b.c) аналогично Roslyn C# (ни свойство b, ни свойство c не вычисляются, если a даёт null).

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

N>Я так понял, что он интересуется, что означает выражение a?.b.c в Nemerle.
N>Или же это (a?.b).c (что может бросить NRE, если (a?.b) даёт null), или оно имеет смысл a ? («значение-a-если-не-null».b.c) аналогично Roslyn C# (ни свойство b, ни свойство c не вычисляются, если a даёт null).

Реализована вторая семантика: если a != null, то вычисляем цепочку дальше.

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

VD>В немерле мы "?[" не реализовывали. Как-то на практике не требовалось.

В Nemerle он не требуется, потому что мы можем дергать индексные свойства по имени (x?.Items[i]).

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

Вот эта посылка не верна

_NN>Nemerle:
_NN>a?.b().c() --> (a?.b()).c() --> (if(a != null) a else null).b().c()


Вот исходник макроса ?.

  macro @?. (expr1, expr2)
  {
    def makeMemberAccess(loc, n) { PExpr.Member(loc,  <[ e1 ]>, Splicable.Name(loc, n)) }
    def makeComplation  (loc, n) { PExpr.Member(loc,  <[ e1 ]>, Splicable.HalfId(loc, n)) }
    def loc = expr2.Location;
    def e2 =
      match (expr2)
      {
        | Ref(n)                    => makeMemberAccess(loc, n)
        | Call(Ref(n), parms)       => PExpr.Call(loc, makeMemberAccess(loc, n), parms)
        | Indexer(Ref(n), parms)    => PExpr.Indexer(loc, makeMemberAccess(loc, n), parms)
        | ToComplete(n)             => makeComplation(loc, n)
        | Call(ToComplete(n), _)    => makeComplation(loc, n)
        | Indexer(ToComplete(n), _) => makeMemberAccess(loc, n)
        | _ => Message.FatalError(expr2.Location, $"The expression of this ($(expr2.GetType())) type not supported with operator '?.'");
      };

    <[
      def e1 = $expr1;
      mutable result;

      when (e1 != null)
        result = $e2;

      result
    ]>
  }