Skip to content

Latest commit

 

History

History
92 lines (60 loc) · 3.32 KB

LDM-2024-04-17.md

File metadata and controls

92 lines (60 loc) · 3.32 KB
Raw

C# Language Design Meeting for April 17, 2024

Agenda

Relax Add requirement for collection expression conversions to types implementing IEnumerable

#8034

Discussion

This was a continuation of Monday's conversation on the conversion rules for collection expressions.

These rules were tightened at LDM-2024-01-10 to require target types that implement IEnumerable, and that do not have create method, to have an accessible Add instance or extension method that can be invoked with value of iteration type as the argument. That is a breaking change for collection types where the Add method has a parameter type that is implicitly convertible but not identical to the iteration type.

The proposal was to relax the requirement (for conversion) and simply require an instance or extension Add method that can be invoked with a single argument, but without requirements on the method parameter type. Later method resolution will reject any Add methods that will not work with the type.

Conclusion

The LDM ratified the proposal that was already checked in, which rolls back some of the changes from January and better aligns the three features: collection expressions, collection initializers, and params collections.

Extensions

Discussion

Today we looked at the syntax for extension types.

This is the information that the syntax needs to be able to express:

  1. It's an extension
  2. Implicit vs explicit concept
  3. It has an underlying type
  4. (Later: base extensions and interfaces)

The current interim syntax implementation is:

implicit extension Extension for UnderlyingType : BaseExtension, Interface { }

Proposed syntax alternatives for the declaration of type:

  • (implicit | explicit) extension
  • (role | extension)
  • view
  • shape
  • alias
  • this (as in this E of U)
  • ??

Proposed alternatives for the keyword options for underlying type:

  • for
  • of
  • extends
  • on
  • over
  • is
  • override
  • using
  • from
  • parentheses or other glyph
  • after the colon with base extensions and interfaces

Several other syntax ideas were also presented in the meeting.

Other thoughts

Extension methods vs. extension type members

We have an open question around how lookup works when there are both implicit extension members and old-style extension methods in the mix. We need to make sure our decisions don't handcuff the BCL or others from adopting the feature.

Traditional extension methods could infer type arguments from all arguments, but extension types can only use the receiver to determine compatible extension types and substitute them.

Priorities

Priorities: static -> instance -> inheritance -> interfaces

Questions that were tabled for now:

  • Can implicit or explicit be omitted? What's the default?
  • What's the naming convention

Conclusion

We will move forward with the current syntax:

implicit extension Extension for UnderlyingType : BaseExtension, Interface { }