Params Collections: Add a bunch of PROTOTYPE comments and a couple of VB tests. #71598
Conversation
dotnet-issue-labeler
bot
added
the
untriaged
|
@333fred, @dotnet/roslyn-compiler For the second review, please. |
| ' The old VB compiler will not be able to consume them decorated with ParamArrayAttribute neither in normal, nor in expanded form. | ||
| ' Therefore, an addition of 'params' modifier is likely to be break VB consumers, and very likely consumers from other languages. | ||
| ' We possibly could fix up the new version of VB compiler, but I am not sure it would be worth the effort since we can | ||
| ' simply use a different attribute, which is likely to work better for other languages too. |
There was a problem hiding this comment.
General question: would a different constructor work as well? IE, if we added a ParamArray(int version) constructor, could we avoid having to add an entire new attribute?
There was a problem hiding this comment.
General question: would a different constructor work as well?
It would work for VB, I think. But might not work for other compilers/tools.
There was a problem hiding this comment.
BTW, we can synthesize an attribute type when it is not available, but we cannot inject a constructor into an existing type.
There was a problem hiding this comment.
True, but I don't expect us to synthesize this attribute. In .NET 8, we tried to move most of the standard embedded attributes into the BCL, and I expect us to continue doing in so in the future. I don't think we should synthesize such an attribute.
There was a problem hiding this comment.
I don't think we should synthesize such an attribute.
I think this is what we have been doing recently for all attributes implicitly applied by compiler (as opposed for attributes applied by user explicitly). We do add the attributes to BCL as well, but do not fail when the type isn't available.
There was a problem hiding this comment.
I think this is what we have been doing recently for all attributes implicitly applied by compiler (as opposed for attributes applied by user explicitly)
No, we've been inconsistent about that. Required does not, nor does ref readonly parameters.
There was a problem hiding this comment.
No, we've been inconsistent about that.
Perhaps. It is quite possible there are outliers. And probably there are good reasons why they are. It is quite possible that the new attribute will fall in to the same category. But, at the moment, that is not obvious to me.
There was a problem hiding this comment.
I, personally, do not see a downside of synthesizing the attribute type for params.
AlekseyTs
merged commit 55b6a79
into
dotnet:features/ParamsCollections
No description provided.