LDM-2022-05-11.md

C# Language Design Meeting for May 11th, 2022

Agenda

1. Inconsistency around accessibility checks for interface implementations
2. ref readonly method parameters
3. 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

dotnet/roslyn#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

#6010

Following up after the last meeting 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 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

#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.