csharplang/meetings/2022/LDM-2022-02-09.md

C# Language Design Meeting for February 9th, 2022

Agenda

1. Continue discussion of checked user-defined operators
2. Review proposal for unsigned right shift operator
3. Review proposal for relaxing shift operator requirements
4. Triage champion features

Quote(s) of the Day

• "Sorry, Jared, gonna have to veto that. Somebody else say something funny in the next 40 minutes"

Discussion

Checked user-defined operators (cont'd)

https://github.com/dotnet/csharplang/blob/main/proposals/checked-user-defined-operators.md

• We discussed the expected behavior for checked operators in Linq expression trees. Checked operators will be supported via UnaryExpression and BinaryExpression expressions in tree.
  • The BinaryExpression already supports Checked expression types that determine whether or not the operation is occuring in a checked context.
  • The MethodInfo stored in expression.Method will provided information about whether or not the operator used is a checked operator.
• We discussed the possibility of supporting invoking checked operators in dynamic invocations.
  • Behavior can be adjusted in Core but not in framework
  • We discussed the possibility of disabling the feature on platforms that do not support dynamic invocation via a runtime flag through RuntimeFeature.
    • This would be the first time that we introduce a runtime feature flag for a C# langauge feature as they are typically intended for runtime limitations.
  • We discussed the set of possible options for resolving this:
    • Option 1: Do not add support for this.
    • Option 2: Only implement for CoreCLR and assume that dynamic evaluation behavior will be different in Framework.
    • Option 3: Adjust the runtime binder across all platforms (most expensive option).
  • There is prior art for scenarios where we have added language features but did not make modifications to the runtime binder, such as for default interface methods.
    • We acknowledge that support has been added for smaller features in the past but that we don't consistently evolve the runtime binder with the language.
  • Conclusion: We will investigate the cost of adding support for checked operators in dynamic invocation in CoreCLR and pursue an implementation if the cost is not too high.

Unsigned right shift operator

https://github.com/dotnet/csharplang/blob/main/proposals/unsigned-right-shift-operator.md

• We examined the behavior of support unsigned shift operator as a built-in and user-defined operator.
• The unsigned shift operator will generally match the behavior of other shift operators when it comes to aspects around grammar ambiguities, precedence, and more.
• The operator will support target the same built-in types as the signed right shift operator.
  • ⚠️ The spec currently outlines that the right shift operator supports fewer types than it actually does. For example, the right shift operator does support target nints and nuints but this is not documented. We should follow up on updating the spec to synchronize with the acactualmplementation.
  • To this end, the unsigned shift operator will support the same set of types that the signed shift operator does in implementation.
• We discussed some of the challenges around supporting >>> in Linq expression trees.
  • Proposal 1: For user-defined operators, a BinaryExpression node targeting the operator method will be created. For built-in operators, a BinaryExpression node will only be created if the first operand is an unsigned type. For scenarios where the first operand is a signed type, a conversion from signed to unsigned will happen before the BinaryExpression node is created, then converted back to a signed type.
  • Proposal 2: Do not add support for >>> in Linq expression trees as part of this change.
  • Proposal 3: Do not add support for >>> in Linq expressions as part of this change but place to introduce a new node type for handling unsigned types in BinaryExpressions.
  • Conclusion: We'll adopt Proposal 3 and not add support for >>> in Linq expressions in the initial phase of this work.

Relaxing shift operator requirements

https://github.com/dotnet/csharplang/blob/main/proposals/relaxing_shift_operator_requirements.md

• To support some generic math scenarios, we are relaxing the requirements for shift operators so that the right-hand operator is no longer restricted to an int type.
• We recognize that the restrictions on the type of the second operand were placed intentionally to avoid unintended behavior (e.g. cout << "foobar") but recognize that the benefits of relaxing the constraint outweight the benefit of stricter requirements on the operator.
• Conclusion: We support relaxing the constraints to support these new scenarios and recognize that this opens the door to strange behavior.

Triage

Collection literals

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

• This proposal already has general approval from LDM but needs to be fleshed out further in a working group.
• Conclusion: Place this issue in the Working Set milestone.

Label statements

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

• This proposal outlines adding support for label as a statement on its own to avoid scenarios where a :; has to follow labels that are defined at the end of a scope, which impacts readability.

if (!Condition()) goto AfterWork;
Work();
AfterWork:;

• This issue was discovered in the context of the Regex source generator, but since labeled statements are frequently used in high-performance code it can also appear in non-generated source as well.

• Conclusion: The problem is valid and the proposed solution is elegant and non-invasive. Place this issue in the Any Time milestone due to lack of urgency.

Roles and extensions

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

• This issue has been previously discussed in an LDM and is being followed up on.
• Conclusion: Place in Working Set milestone.

"file private" Visibility

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

• This proposal outlines adding a mechanism to support limiting the visibility of a types to a particular file.
• Other lanuages have the ability to hide types from other files in the build including signature implementation files in F# and package level visibility configuration in Go.
• There was a variety of discussion about the pros/cons of different levels of visibility for this feature including file-based visibility and namespaced-based visibility to support for local types.
  • Implementations in other languages have varied levels of scoping from file-based to type-based.
• Conclusion: We generally agree that there is merit to solving this problem, but some more details need to be fleshed out before we can examine the proposal more fully. Marking this one as a candidate for surfacing back to the committee.

Adding Index support to existing library types

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

• This proposal outlines adding support for implicit Index types to existing library types (e.g. List.Remove) to allow existing overloads to work with indexors.
• We discussed some general concerns around overload resolution with this change and the need to have sensible rules for when an Index type is supported in a feature.
  • The current proposal limits this implicit support to APIs that accept an int index parameter but this does not capture:
    • APIs that might use other types, such as long, particularly for those that are in libraries targeting "big data" scenarios (machine learning, GPU-based work, etc.)
    • APIs that use alternative parameter names (e.g.position or offset) for arguments that can be treated as indexors.
    • Scenarios where an API might have multiple arguments (e.g. (int index, int length) ) not all of which can be treated as an index.
• We discussed the benefits of this work, particularly in reducing the number of new overloads that need to be added and ensuring that users don't have to be on a particular version to use the new Index-based APIs.
• We discussed whether it would be sensible to provide an opt-in or an opt-out for some of the functionality to account for scenarios where the overload resolution in a way that doesn't adhere to the users expectations
• Conclusion: Place in Working Set milestone and bring it as an agenda item in an upcoming LDM meeting.