# C# Language Design Meeting for May 11th, 2022

## Agenda

1. [Inconsistency around accessibility checks for interface implementations](#inconsistency-around-accessibility-checks-for-interface-implementations)
2. [`ref readonly` method parameters](#ref-readonly-method-parameters)
3. [Pattern matching with UTF-8 String Literals](#pattern-matching-with-utf-8-string-literals)

## Quote of the Day

- "Did [redacted] turn their camera on? I'm in trouble."

## Discussion

### Inconsistency around accessibility checks for interface implementations

https://github.com/dotnet/roslyn/issues/60885

A small group went back and looked at this issue, to come up with a more palatable solution to the problem than the existing proposals. Unfortunately, our hands
are somewhat tied here, as the runtime does not do any form of assembly accessibility checks. If the signature of a new interface member (DIM or not, `internal` or
not) lines up with an existing member of a type that implements that interface, the runtime will consider that existing member to be an implementation of the
interface member. We therefore think the best we can do is to perform a real accessibility check at compile-time. This isn't something we do today, and will prevent
the user unintentionally getting into this scenario at compile time. While it can still be observed at run-time due to an upgraded assembly version, this is no
different than other existing breaks when introducing new members into interfaces.

#### Conclusion

Perform a real accessibility check for implementations of internal interface methods, and error if the check fails.

### `ref readonly` method parameters

https://github.com/dotnet/csharplang/issues/6010

Following up after the [last meeting](LDM-2022-05-09.md#ref-readonly-parameters) on `ref readonly` parameters, we discussed the call site rules for `ref readonly`
parameters. We were dissatisfied with the rules we decided in our [first meeting](LDM-2022-04-25.md#ref-readonly-method-parameters) on the feature, which stated
that `ref readonly`'s "natural" calling convention would be `in`, and using `ref` at the call site would be supported, but have a warning. This felt off, as `in`
at the declaration site has been redefined to be `ref readonly` + convenience features. Using `in` at the call site, therefore, is a mismatch. We also have
precedent in the language for `ref`, as that is what is required for `ref readonly` returns. At the same time, using `ref` at the call site doesn't always sit right
either, as `ref` indicates danger: the method being called can see and modify your value. This danger signal is why `ref` is required at the call site in the first
place, instead of following the C++ pattern of implicit by-ref parameters. In some ways, we think that there's an argument for allowing `ref readonly` parameters to
simply be silent, rather than requiring any specifier; many of the same arguments for `in` apply to `ref readonly` at the call site as well. We have lifetime rules
to flag truly unsafe value capturing, and `ref readonly` ensures that a call can't mutate the value from under the caller. That being said, however, the main use
cases we are looking at the `ref readonly` feature will benefit from some marker at the call site. A key distinction of most of the APIs we're considering is that
they capture or return refs from these parameters, and a marker of some kind is a good thing for such scenarios.  We also need to consider that we will have APIs
migrating to `ref readonly` from both `ref` and from `in`, so existing code will have potentially any or no existing markers.

To resolve these constraints, we've come up with the following set of rules, which cover call site conventions for `ref`, `ref readonly`, and `in` parameters:

| Call site annotation | `ref` parameter | `ref readonly` parameter | `in` parameter |
|----------------------|-----------------|--------------------------|----------------|
| `ref`                | Allowed         | Allowed                  | Warning        |
| `in`                 | Error           | Allowed                  | Allowed        |
| No annotation        | Error           | Warning                  | Allowed        |

* `ref` and `ref readonly` parameters require lvalues at the call site.
* `in` allows lvalues or rvalues at the callsite.

#### Conclusion

See the above table and bullets.

### Pattern matching with UTF-8 String Literals

https://github.com/dotnet/csharplang/discussions/6036

Finally today, we looked at pattern matching for UTF-8 string literals, particularly against inputs of `ReadOnlySpan<byte>`. This is similar to the work we did for
`string` for C# 11, where you will be able to pattern match an input of `Span<char>` against string literals. We're generally supportive of this, and we have a broader
goal in mind: we'd eventually like `u8` literals to _be_ constants. The runtime would need to be updated to support this (as the CLI spec doesn't indicate that
UTF-8 literals are supported as constant values today), but we are in support of steps along the journey of making `u8` literals appear as constants, including pattern
matching support. We don't think this is top priority, though, so while we would accept a community contribution to create a specification for how this would work, we
won't be actively working on it at this time.

#### Conclusion

We will review a community-contributed specification for this feature.
