# C# Language Design Meeting for April 15, 2024

## Agenda

- [Non-enumerable collection types](#non-enumerable-collection-types)
- [Interceptors](#interceptors)
- [Relax `Add` requirement for collection expression conversions to types implementing `IEnumerable`](#relax-add-requirement-for-collection-expression-conversions-to-types-implementing-ienumerable)

## Non-enumerable collection types

- Championed issue: [#7744](https://github.com/dotnet/csharplang/issues/7744)
- Requested details: [#7895](https://github.com/dotnet/csharplang/pull/7895)

Should collections that are not enumerable be usable in collection expressions and `params` collections, if they have a `CollectionBuilder` attribute that defines a single `Create` method?

In this case, the element type of the collection can be determined from the `Create` method if it is not already known.

Changes to the spec had been previously discussed and the details changes were reviewed, as shown in #7895 and #7744. This discussion was to confirm approval of the spec change.

### Conclusion

These proposed changes were approved.

## Interceptors

- [Open issues for interceptors](https://github.com/dotnet/csharplang/blob/ff2c82c8d702d70e2704cd9265c97859cc2eb296/proposals/interceptors-issues-2024-01.md)

### File location

Interceptors must identify the location in code where interception occurs. The issue is how to identify that location for use in the interceptor attribute.

Things that have been tried or considered for identifying the file:

* Absolute paths, per the preview, are bad for portability.
* Relative paths required the context be passed around or a project base path.

The proposed arguments to `[InterceptsLocation]` are a version number and an opaque data string. The opaque data string is not intended to be human readable. It is expected that this string will be inserted by a generator that retrieves it via a call into the interceptors API that requests an interceptible location.

The proposal is to create the opaque string by combining a checksum of the file contents, an integer location of the call in the syntax and a string file name for error reporting. Hand authoring interceptor locations is an unsupported scenario.

A version identifier is included to allow future change to be made in the calculation of the data string.

### Other public API changes

The team also mentioned that there is an experimental public API that lets you determine whether syntax is being intercepted and who is intercepting. This might be used in an analyzer, for example.

### Conclusion

The proposed approach to identifying the file location was approved, including the proposed handling of version.

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

[#8034](https://github.com/dotnet/csharplang/issues/8034)

We introduced a breaking change in 17.10 which had a larger impact than anticipated. The proposal is to resolve that breaking change. It occurs when:

* Types that implement `IEnumerable` but not `IEnumerable<T>` and have a strongly-typed `Add(T)`.
* Types that implement `IEnumerable<T>` and have a strongly-typed `Add(U)` where `U` is implicitly convertible to `T`. This is a generic form of category 1.
* Types that implement `IEnumerable<T>` and have a strongly-typed `Add(U)` where `U` and `T` are unrelated.

The breaking change added in 17.10 was the additional restriction:

* `Add` needs to have one parameter of the iterator type

The proposal is to keep the `Add` method, still require a single `Add` parameter but no statement about the type of the argument.

### Conclusion

No conclusion reached and this will be discussed again in the April 17 meeting.
