# C# Language Design Meeting for April 17, 2024

## Agenda

*  [Relax `Add` requirement for collection expression conversions to types implementing `IEnumerable`](#relax-add-requirement-for-collection-expression-conversions-to-types-implementing-ienumerable)
* [Extensions](#extensions)

## Relax `Add` requirement for collection expression conversions to types implementing `IEnumerable`

[#8034](https://github.com/dotnet/csharplang/issues/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](https://github.com/dotnet/csharplang/blob/main/meetings/working-groups/roles/roles-2023-02-15.md#what-keyword-for-underlying-type).

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:

```csharp
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:

```csharp
implicit extension Extension for UnderlyingType : BaseExtension, Interface { }
```
