Remaining work for discards, tuples and out variables

[MadsTorgersen]

I'm using this issue to evacuate remaining unresolved conversations and pending improvements from PR #664, so that it can get merged without losing track of them.

• More examples: Several parts of the PR are short on examples, e.g.:
  • Deconstruction expressions (https://github.com/dotnet/csharpstandard/pull/664/files#r1145443903)
  • Deconstructing assignments
• Annotation of examples for testing
• Tuple encoding(https://github.com/dotnet/csharpstandard/pull/664/files#r1145298345, https://github.com/dotnet/csharpstandard/pull/664/files#r1145285224):

  The compiler usually constructs the underlying ValueTuple<> chain. If the program constructs an n-tuple directly using ValueTuple<> then is the code potentially non-portable between implementations which declare a different number of ValueTuple<> sizes? Or does the compiler accept only flat new ValueTuple…?
  This says an n-tuple in different implementations could be represented by a chain of q m-tuples and a final p-tuple where n = q × (m-1) + p and m is implementation dependent number. Do we need to say anything about how one implementation handles tuple values created by another with a different m?

• Declaration spaces (https://github.com/dotnet/csharpstandard/pull/664/files#r1112356059):

  Additional contexts that might not be covered by this yet:

  • Pattern variables declared in a switch (case) label. This one is subtle because it introduces a scope that encompasses just the switch section, nested within the switch block, but local variables declared in the statements of the switch section go in the scope of the switch block.
  • A switch case guard (when clause). These go in just the switch block's scope (see previous bullet).
  • A query clause
  • A catch block, where the exception variable is introduced. Its absence looks like a bug in the previous version. This will take care of expression variables in an exception filter as well.

[jskeet]

I'll check that these were done in the end (or create a PR, or ask for more help).

[jskeet]

More examples: this is a nice-to-have. We should do it, but it shouldn't block the C# 7 standard from going out.

Annotation of examples for testing: I believe Rex has done these; @RexJaeschke can you confirm?

Tuple encoding: I'm not sure whether it was present before, but we have this note:

Note: There does not need to exist a System.ValueTuple<...> declaration that directly matches the arity of any tuple type with a corresponding number of type parameters. Instead, larger tuples can be represented with a special overload System.ValueTuple<..., TRest> that in addition to tuple elements has a Rest field containing a nested tuple value of the remaining elements. Such nesting may be observable in various ways, e.g. via the presence of a Rest field. end note

Proposal: I'll create a PR to add this to annex B.3.

Declaration spaces:

• I note that we don't cover declaration_pattern at all in section 7.7.1, which is the first place I looked. Is that a problem?
• The rest of the "work to be done" looks like it still needs to be done. @gafter you originally raised this - are you in a good position to create a PR to address it?

[RexJaeschke]

@jskeet

Annotation of examples for testing: I believe Rex has done these; @RexJaeschke can you confirm?

I have done this for PRs merged up to the most recent meeting. At that meeting, we closed PR #742, which I see has 4 new, small examples (in variables.md). I plan to add annotation to these after tomorrow's call, when I will do likewise for PR #795, assuming we merge that.

[KalleOlaviNiemitalo]

7.6 Signatures and overloading states that object and dynamic are equivalent in signatures.

csharpstandard/standard/basic-concepts.md

Line 544 in 4939f48

The types `object` and `dynamic` are not distinguished when comparing signatures. Therefore members declared in a single type whose signatures differ only by replacing `object` with `dynamic` are not allowed.

It is not necessary to add a sentence saying that tuple element names do not affect signature equality, because this follows from the identity conversions that are already specified.

csharpstandard/standard/basic-concepts.md

Line 531 in 4939f48

- Two signatures of the same member kind (method, instance constructor, indexer or operator) are considered to be the *same signatures* if they have the same name, number of type parameters, number of parameters, and parameter-passing modes, and an identity conversion exists between the types of their corresponding parameters ([§10.2.2](conversions.md#1022-identity-conversion)).

csharpstandard/standard/conversions.md

Lines 82 to 86 in 4939f48

	In some cases there is an identity conversion between types that are not exactly the same, but are considered equivalent. Such identity conversions exist:
	- between `object` and `dynamic`.
	- between tuple types with the same arity, when an identity conversion exists between each pair of corresponding element types.
	- between types constructed from the same generic type where there exists an identity conversion between each corresponding type argument.

[jskeet]

Meeting 2023-09-06:

• "More examples" can be a maintenance task, post C# 7 release (or potentially while it's out for ECMA review)
• Declaration spaces work assigned back to Mads

[jskeet]

Closing, as we'd like more examples, but the blocking aspects are done.

[jskeet]

Reopening with C# 8 milestone and clarity label for the examples.