Create params-collections.md proposal #7661
Conversation
| Also, one might say, that with [collection expressions](https://github.com/dotnet/csharplang/blob/main/proposals/csharp-12.0/collection-expressions.md) | ||
| now in the language, there is no need to extend `params` support at all. Foe any collection type. To consume an API with collection type, a developer | ||
| simply needs to add two characters, `[` before the expanded list of arguments, and `]` after it. Given that, extending `params` support might be an overkill, | ||
| especially that other languages are unlikely to support consumption of non-array `params` parameters any time soon. |
There was a problem hiding this comment.
right. this was the POV of a few people the last time we discussed this. namely, that it's totally fine to just have the user write [...] around teh arguments. THe critical case as params Span because in that case we want the API developer to be able to add the overload and have it take precedence over the array version, just by recompiling (so no change to the callsite).
--
Note: i'm personally fine going either way. params collection seems the most consistent approach to take. but params span also seems sufficient. #Resolved
There was a problem hiding this comment.
It's probably worth expanding the "we at least need to do params Span so the BCL can offer better overloads" part explicitly here.
There was a problem hiding this comment.
The better overloads part is definitely a big motivator for this feature.
There was a problem hiding this comment.
The better overloads part is definitely a big motivator for this feature.
I will make sure to clearly capture this in the "Motivation" section.
| ; | ||
| ``` | ||
|
|
||
| A *parameter_collection* consists of an optional set of *attributes*, a `params` modifier, an optional `scoped` modifier, |
There was a problem hiding this comment.
Feels like we should have an open question on whether to permit scoped for params, or if we should always infer it if the type is a ref struct, similar to how we do for this and out parameters. #Resolved
There was a problem hiding this comment.
When params modifies a ref struct parameter I think scoped should be implicitly enabled. The number of cases where you want that is virtually 100% when looking through the BCL cases. If it turns out that there is need / demand for it to be not scoped in a few cases then we could augment the design to support [UnscopedRef] here but I wouldn't want to do that without a strong supporting scenario.
There was a problem hiding this comment.
Feels like we should have an open question on whether to permit scoped for params, or if we should always infer it if the type is a ref struct, similar to how we do for this and out parameters.
I captured what I am proposing. You should be able to raise concerns, if any, during LDM discussion.
There was a problem hiding this comment.
I think it is good to capture any known open questions before LDM. This is one such question.
|
|
||
| A *parameter_collection* consists of an optional set of *attributes*, a `params` modifier, an optional `scoped` modifier, | ||
| a *type*, and an *identifier*. A parameter collection declares a single parameter of the given type with the given name. | ||
| The *type* of a parameter collection shall be one of the following valid target types for a collection expression |
There was a problem hiding this comment.
Could we not simplify this list by just specifying that there must exist a collection expression conversion from a collection expression to the target type? #Resolved
There was a problem hiding this comment.
Could we not simplify this list by just specifying that there must exist a collection expression conversion from a collection expression to the target type?
First, there is no collection expression. Second, I intentionally exclude the nullable value type case.
| Also, one might say, that with [collection expressions](https://github.com/dotnet/csharplang/blob/main/proposals/csharp-12.0/collection-expressions.md) | ||
| now in the language, there is no need to extend `params` support at all. Foe any collection type. To consume an API with collection type, a developer | ||
| simply needs to add two characters, `[` before the expanded list of arguments, and `]` after it. Given that, extending `params` support might be an overkill, | ||
| especially that other languages are unlikely to support consumption of non-array `params` parameters any time soon. |
There was a problem hiding this comment.
It's probably worth expanding the "we at least need to do params Span so the BCL can offer better overloads" part explicitly here.
Co-authored-by: Jan Jones <[email protected]>
No description provided.