LDM Notes for February 23rd, 2022

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2022/LDM-2022-02-23.md

Agenda

1. Pattern matching over Span<char>
2. Checked operators

[sab39]

Defining the feature in terms of SequenceEqual seems to rule out the possibility of the compiler doing any clever optimizations for a switch where all the patterns are constant strings. Is that a concern? I've no idea whether optimizations like that are really worth it in practice.

[jnm2]

I suspect that if ValueTuple resolved at compile time to a type with a user defined operator==, it would be used.

@sab39 A custom operator == on ValueTuple can't be used in principle. Semantics are completely different. (a, b) == (c, d) does not behave like (a, b).Equals((c, d)). Instead, it behaves like a == c && b == d, possibly calling user-defined operators on T1 and T2 which Equals doesn't do and a custom operator == can't do.

[sab39]

(a, b) == (c, d) does not behave like (a, b).Equals((c, d)).

Right, that's why I referred to operator== instead of Equals().

Either way, my point is that whatever the semantics are, they should be described by the spec. If the spec says that (a, b) == (c, d) should be compiled as a == c && b == d then that's what the compiler should do. If the spec doesn't say that, then it implicitly would inherit the specified behavior of the == operator which will use a user-defined operator if an applicable one exists, and the semantics of that operator would be part of the documentation of what operators exist on ValueTuple.

[sab39]

Maliciously-defined frameworks are something we try to be resilient to, but not something we will intentionally design around. If you have a misbehaving SequenceEqual, then bad behavior will result.

@333fred sure - I'm not suggesting to be resilient to it in the code, but that the language specification is supposed to be precise about what the behavior is (which I would assume is part of the reason why it provides details about how the methods are resolved in the first place). It sounds like you're already planning to do exactly what I was advocating in the actual code, I'm just suggesting that the spec correctly reflect that. Something like:

... the pattern is considered matching if e.Length == c.Length and e[i] == c[i] for all characters in e. The compiler may assume that this is equivalent to MemoryExtensions.SequenceEqual(e, c). If it is not, then the behavior is unspecified.

[333fred]

@sab39 that's why I started by saying that it will be vague enough to permit what we're doing. But at the end of the day, it needs to say that we will call that method, because if that method is not present we will fail to compile the code.

[sab39]

Sounds perfect. (although if we want to be really pedantic, all we need to say is "if the method is not present we will fail to compile the code"; whether we actually ever call it or not is unspecified)

[BreyerW]

Personally i would require unchecked keyword all in the name of explicitness/explicit intents. With ide support its not that long to type

That being said i would at least throw away allow but not require case since that will let mix declaring styles within same project which to me isnt ideal.

Disallow is fine too at least there will be no chance of ever so slight confusion due to mix of styles

Just my 2 cents

[333fred]

That being said i would at least throw away allow but not require case since that will let mix declaring styles within same project which to me isnt ideal.

What does this refer to?

[BreyerW]

In the notes it was mentioned ldm members are roughly split evenly between requiring keyword for unchecked operators, allowing but not requiring and disallowing. Personally i would only consider 1st and 3rd option thus throwing away 2nd.

If you are asking about mixing styles then as i understand 2nd option would let you write unchecked operators with and without keyword even within same class eg.

class example{

public static example unchecked operator+(...){...}
public static example operator-(...){...} //unchecked operator too

}

Which makes me wince a little. That being said i dont feel too strongly about it. It can be enforced one way or the other with style guides but thats the thing thats yet another thing for style enforcers to implement and for programmers to be aware of

EDIT: I have looked at how defining custom operators worked in past c# versions and theres no unchecked keyword used so if you start requiring keyword in the presence of checked operator then adding checked operator to existing class with unchecked operators will cause somewhat unexpected break in place that you werent working on. I think for ergonomic reasons only 2nd or 3rd option should be taken into account bc of this gotcha

[333fred]

then adding checked operator to existing class with unchecked operators will cause somewhat unexpected break in place that you werent working on. I think for ergonomic reasons only 2nd or 3rd option should be taken into account bc of this gotcha

Personally, I view this as a positive thing. It forces the user to understand what they are doing to their existing operator when they add a checked version.