Added: C# Language Design Notes for Jun 27, 2017

[MadsTorgersen]

C# Language Design Notes for Jun 27, 2017

1. User-defined operators in interfaces
2. return/break/continue as expressions

Please discuss.

[tannergooding]

The compiler already warns when ==/!= are implemented but the user does not also implement Equals/GetHashCode (CS0660 and CS0661).

I feel like the compiler could continue emitting the same warning for classes/types that implement an interface which defines ==/!= but where class/struct does not also implement Equals/GetHashCode.

[orthoxerox]

Pardon me if I'm wrong, but wouldn't == and != be implemented explicitly, as any other default method? That is:

interface IEq<T> where T:IEq<T>
{
    bool Equals(T other); 
    publiс static bool operator==(T left, T right) => left.Equals(right);
    publiс static bool operator!=(T left, T right) => !left.Equals(right);
}

public class C : IEq<C>
{
    public bool Equals(C other) => true;
}

var c1 = new C();
var c2 = new C();
var bool1 = c1 == c2; // object.ReferenceEquals(), returns false
IEq<C> eq1 = c1;
IEq<C> eq1 = c2;
var bool2 = eq1 == eq1; // IEq<T>.Equals(), returns true

That doesn't look good, but if they are accessible via the implementor, then it won't be possible to add them to IEquatable<T> (which is arguably the interface that needs them the most), it will be a breaking change since a call to object.ReferenceEquals will be replaced with a call to IEquatable<T>.Equals upon recompilation.

[HaloFour]

For the sake of completeness what about goto expressions as well? Although if that makes people more skeptical about the clarity of the code or potential for abuse then please forget I ever mentioned it.

Where I'd really think it would be interesting to support break/continue expressions would be within LINQ queries where they could be interpreted as calls to TakeWhile or Where respectively.

[gulshan]

I would vote for the return expression as it is more throw-like but against the break and continue expressions which in my opinion decreases the readability of the code.

[yaakov-h]

On user-defined operators:

interface IA { public static int operator+(IA a, int n) => 1; }
interface IB { public static int operator+(IB b, int n) => 2; }
class C : IA, IB { }
(new C()) + 5;;

What happens on the hypothetical line 4 above?

• Is the result 1, or 2?
• Does C get a + operator outright? Would it have to be cast to IA or IB first?
• Would it just throw like the current DIM proposal?
• Compiler error?

[alrz]

The scenarios involving the ternary conditional operator seem less compelling

It can be useful, for example:

var identifier = node.IsKind(IdentifierName) ? (IdentifierNameSyntax)node : continue;

// vs

if (!node.IsKind(IdentifierName))
{
    continue; 
}

var identifier = (IdentifierSyntaxName)node;

I've deliberately used brackets (as we do in Roslyn) to show how it actually looked before rewrite.

Note: there certainly are other alternatives for this specific example, but I'm just trying to see what we can do with continue/break and whether it's a good idea or not.

In other cases, it would help you to avoid figuring out a filler value for the false part e.g. default, etc.

var kind = 
    prefix is null ? NumericKind.Decimal 
    : prefix.Equals(hexPrefix) ? NumericKind.Hexadecimal
    : prefix.Equals(binaryPrefix) ? NumericKind.Binary
    : return; // instead of NumericKind.Unknown

---

@gulshan

I would vote for the return expression as it is more throw-like but against the break and continue expressions which in my opinion decreases the readability of the code.

In my example above, how it would be any more readable if I wanted to return instead? I think return vs break/continue argument regarding readability doesn't make much sense, your code won't be more readable suddenly, if you want to return early vs. continue the loop! that depends on what you're trying to do. I agree, both are subject to abuse (just like throw expressions) but when you're actually in need, it could be really useful.

[gulshan]

Actually I was not comparing return expression with break and continue expressions and I agree that comparison doesn't make any sense. I was simply saying I would go for return expressions for it's usability. But break and continue expressions, which will most probably be used during processing lists, will make codes shorter but less readable in my opinion. I have argued the same in the main issue- #176 (comment)

[MadsTorgersen]

@orthoxerox Good point: there's a bit of a smell to ==/!= that way.

@HaloFour Yeah, if we do all the other _jump-expression_s, we should probably do goto as well for completeness. Hopefully it won't see much use!

@alrz Those are good examples; I totally buy them. Thanks!

The general gist of the examples here and elsewhere seems to be that you are producing a value through conditional logic in an expression. A residual case where you fail to produce a value would force you into one of:

• stepping out of "expression mode" and rewriting the whole thing in a statement style
• flowing through a "failure value" and recognizing that at the statement level
• using throw, which is allowed in an expression context today

All of return, break and continue seem like valid ways of recovery from a failure to produce a value (and goto would come along for the ride). Whether it's "I'm done with this method" (return a result), "I'm done with this loop" (break) or "I'm done with this iteration" (continue).

[Joe4evr]

Oh, now that I get what return/break/continue expressions can do, I'd love this:

var derived = (foo as DerivedFoo) ?? return;

Useful if you have an event handler where you may get a certain base-type, but you only care about one of its derived types.

[MadsTorgersen]

@Joe4evr

You get pretty decent code today with patterns:

if (!(foo is DerivedFoo derived)) return;
// use derived

Though admittedly this example is fodder for another feature request, the isnot expression.

[DavidArno]

@MadsTorgersen,

Like @alrz, I can imagine cases where break, return etc expressions would be use with ternary expressions, as well as for null-coalescing expressions. So it would be good to see them being usable in both.

The main thing I wanted to say though is just how super happy these particular notes make me feel. Not because of the specific content, but because the LDM discussed ideas raised here. It shows that all my previous pessimism over whether this repo served any useful purpose were unfounded. Sometimes, I love being wrong. 😀

I'm now looking forward to other ideas from here being discussed and rejected or championed, over the coming months and years. Happy times. Thanks. 🎉

[MgSam]

I think all jump expressions make sense. I think the scary example the design notes pointed out, M(Foo1(), Foo2() ?? break, int.TryParse(s, out int x) ? x * 10 : continue);, would be awful, unreadable code even without jump expressions, so I see that as being somewhat of a straw man.

@MadsTorgersen Please discuss isnot in an LDM! This, if (!(foo is DerivedFoo derived)) return; is not "pretty decent code". It's totally unreadable- because you have to read it from the inside out and that ! is easy to miss, and annoying to mentally parse.

[bbarry]

There's something unfortunate about calls like these:

M(Foo1(), Foo2() ?? break, int.TryParse(s, out int x) ? x * 10 : continue);

You start computing arguments and then you decide not to do the call. Wouldn't it have been better (at least more efficient) to decide before starting to compute the arguments? Maybe, but that also leads to more ceremony and less locality of the code.

I'm not sure I understand the point here. You could decide before computing the arguments, but it would be different code. The only way to write the above statement today would be in multiple statements:

var t1 = Foo1();
var t2 = Foo2();
var t3 = t2 ?? default(?);
if (t2 == null) break;
int x;
if (int.TryParse(s, out x)) { x = x * 10; } else { continue; }
M(t1, t3, x);

[alrz]

@bbarry

I think the interesting part is the Foo1() call, once either of jumps are reached, Foo1() value is lost because arguments are evaluated in the lexical order. However, instead of locals, you could change that order with argument names (as long it's not a params parameter).

M(second: Foo2() ?? break, third: int.TryParse(s, out int x) ? x * 10 : continue, first: Foo1());

[paulomorgado]

Adding a isnot operator would be only for completeness. Not that !(foo is DerivedFoo derived) isn't readable at all.

And the isnot operator would be the opposite of the is operator in !(foo is DerivedFoo) and would not make any sense to have a foo isnot DerivedFoo derived.

[jnm2]

@paulomorgado It makes sense to have !(foo is DerivedFoo derived) 😈

[yaakov-h]

@jnm2 Logically neither of them make sense, which is why I think a guard-like clause (see Swift) is more reasonable here than is-not.

[jnm2]

Logically neither of them make sense,

How can you support that claim when it's making sense to both me and the compiler? ;-)

foreach (var item in items)
{
    item.Foo();
    if (!(item is Bar bar)) continue;

    bar.Bar();
    barCount++;
    // ...
}

[yaakov-h]

if (item is Bar bar):

If item is of type Bar, then create a locally scoped variable named bar to represent this.

if (!(item is Bar bar)):

If item is not of type Bar, then what am I doing with a local variable of type Bar??

It works, but it doesn't make sense.

[jnm2]

If item is of type Bar, then create a locally scoped variable named bar to represent this.

It's not even locally scoped if I say if (item is Bar bar), but why does it make any less sense if it's not locally scoped?

If item is not of type Bar, then what am I doing with a local variable of type Bar??

Nothing. Which makes sense.

[alrz]

• 👍 isnot
• 😕 is not
• 🎉 !is
• 😆 is!
• 👎 unless, guard, (edit: any negative if statement)
• ❤️ none

somebody had to do it.

[orthoxerox]

To explain my ❤️: I'd support letting the ! be written outside the parentheses if !(item is Bar bar).

[alrz]

That'd be the 5th option. (favor a whole new statement for a negative if). I think that was considered before changing pattern variable scope. But still that's a more general approach which works for any condition.

[iam3yal]

@alrz My answer is a bit more complex than a yes or no. :)

1. isnot looks quite odd and inflexible. (see paragraph 2.)

2. is not I quite like this because not can get generalized and be used in conjunction with other keywords such as when not and maybe where not, dunno just a thought.

3. !is I'm torn on this I like it because it's terse and looks good but dislike it because I don't think it's readable enough to my taste.

4. is! is slightly more readable but then I dislike it because the symbol is on the right-side which is inconsistent with the language imo.

5. unless, guard I'm kinda torn on these but if I had to choose I'd go with unless.

So given these choices I'd either go with 2 or 5.

[HaloFour]

@eyalsk

Nod, is not allows for the exploration of not as its own pattern, particularly when combined with recursive patterns:

switch (obj) 
{
    case (string s, not Foo):  // equivalent to case (string s, var $temp) where !($temp is Foo)
}

[alrz]

@HaloFour

That's my first preference but as discussed (#246) there is some considerations regarding definitive assignment. In short, not is only useful as a top-level pattern when there is a variable (though I don't see it as a full blocker).

[Neme12]

All of this raises the question if the split between statements and expressions was ever a good idea. They seem like totally different universes where you have a lot of the same concepts with a different syntax. With this move we are getting much more comfortable in the 'expression' universe but you will eventually find a reason why you can't go on in this context and have to rewrite the whole thing as a statement. This seems like a really strange duality.

[DavidArno]

@Neme12,

With hindsight, I'd say splitting them was a bad idea; everything should have been an expression. But we are where we are, and we are only there because a general shift toward wanting to do more with expressions these days. So the way forward should be an orderly migration to the point where everything can be treated as an expression. This is one step along that path.