Implemented dotnet/csharplang#323

[lachbaer]

@gafter
I have implemented your proposal dotnet/csharplang#323 together with dotnet/csharplang#328 (default coalescing operator). It wasn't so complicated after all. Maybe there are some side-effects I have overseen?
Currently there are no tests.

I would like to submit a PR for a first review.

(See https://github.com/lachbaer/roslyn/tree/DefaultCoalescingOperator)

Update:
I just encountered a slight problem. In case of

class C1
{
    public int x {get; set;}
    public int? y {get; set;}
}

c?.x ?? 42;
c?.y ?? 42;

the behaviour of a default-coalescing-operator is completely arbitrary. I've got to sort that out, first!
Sorted that out. It behaves as expected by the specs (c?.x gets converted to (int?) and thus has no ambiguity).

[gafter]

@lachbaer To be clear, neither of these are my proposal. The first was proposed by @jacekbe and the second by @lachbaer (you). Neither of these proposals has a champion in the LDM, and neither has been through the language design process to result in a tentative specification against which I could review your implementation.

I am willing to champion the proposal dotnet/csharplang#323 by @jacekbe and get it in the queue for LDM triage. I'm not so excited about dotnet/csharplang#328, but I'm willing to point it out to the LDM as one approach to dotnet/csharplang#323.

See dotnet/csharplang#418

[gafter]

I think we would more likely want dotnet/csharplang#398 rather than dotnet/csharplang#328 .

[lachbaer]

@gafter

To be clear, neither of these are my proposal

Sorry, no offense :-) You opend #323, therefore...

I think we would more likely want dotnet/csharplang#398

That would only be the logical advance for pointers 👍

but I'm willing to point it out to the LDM

Thank you. Anyhow, I took the programming of it as an exercise. 😄

I would like to state some arguments for #328 here:

Pro:

• It doesn't change the current meaning of ??, no code breaks
• Already allows for evaluating pointers ([CodePlex] Bug in SemanticModel.GetAwaitExpressionInfo and expression lambdas #323)
• Wouldn't really hurt to extend the operator to types that aren't respected and just produce semantic errors by now.
• Could lead to new use cases, primarily in numeric algorithms

Contra:

• Could lead to confusion when used with non-nullable intrinsic or value types, e.g. unwanted outcome of the expression
• By now restricted use cases

Neutral:

• Adds complexity to the spec,
  but if you look at the spec know it already is quite complex, not enough documented in the C# Guide and already leads to misunderstandings (see Discussion: Always explicitly type null-conditional operator ?. csharplang#417), especially when used with nullable types. Adding logical complexity wouldn't make much of a difference.
• I am a friend of C/C++'s handling of zero (0) values. C# of course wants to play that game safe. But there are already enough safe binary operators for values, like all the bitwise ones. This addition to ?? also makes it kind of a bitwise operator (on 0-bitted values) without influencing the initial intention.

Maybe, you can make use of the arguments. 😊

[gafter]

@lachbaer I have noted in dotnet/csharplang#418 that you have offered an implementation. Thank you! Please hang on to it in case we decide to move ahead and schedule it for LDM design and implementation. In the meantime I'm closing this issue as it isn't actionable.