meetings/2024/LDM-2024-04-15.md
Add requirement for collection expression conversions to types implementing IEnumerableShould 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.
These proposed changes were approved.
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:
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.
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.
The proposed approach to identifying the file location was approved, including the proposed handling of version.
Add requirement for collection expression conversions to types implementing IEnumerableWe 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:
IEnumerable but not IEnumerable<T> and have a strongly-typed Add(T).IEnumerable<T> and have a strongly-typed Add(U) where U is implicitly convertible to T. This is a generic form of category 1.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 typeThe proposal is to keep the Add method, still require a single Add parameter but no statement about the type of the argument.
No conclusion reached and this will be discussed again in the April 17 meeting.