{"id":35772,"date":"2025-09-29T14:00:08","date_gmt":"2025-09-29T14:00:08","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/cppblog\/?p=35772"},"modified":"2025-09-24T03:57:56","modified_gmt":"2025-09-24T03:57:56","slug":"fixing-overload-resolution-for-parameter-arrays-in-c-cli","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/cppblog\/fixing-overload-resolution-for-parameter-arrays-in-c-cli\/","title":{"rendered":"Fixing Overload Resolution For Parameter Arrays in C++\/CLI"},"content":{"rendered":"

Introduction<\/h2>\n

In the below discussion, <\/span>.NET Framework<\/code> refers to the older version\u00a0<\/span>of the Microsoft Common Language Runtime, also known as “Desktop Framework” (versions 4.0 through 4.8.x) while .NET<\/code>\u00a0 refers to versions .NET Core 3.1<\/code>, .NET 5<\/code> and later.<\/p>\n

The overload resolution behavior specified by the C++\/CLI\u00a0ECMA-372\nStandard for overloads involving parameter arrays results in surprising\nbehavior in some instances. This problem has manifested with recent\nversions of .NET, which added parameter array overloads to some\ncommonly used classes, resulting in overload resolution which is\nsurprising, even counterintuitive, and results in broken customer code\nwhen it is ported from .NET Framework to .NET. This article\nexplains the problem and the solution adopted by the MSVC\ncompiler to solve it.<\/p>\n

Recap of Parameter Array Overload Resolution Rules<\/h2>\n

ECMA-372 section 14.6 details the rules governing overload resolution\nwhere parameter arrays are involved. The method to resolve overloads is\nthat for a given parameter-array overload such as<\/p>\n

    void f(T1 arg1, T2 arg2, <...>, Tm argm, ...array<T>^ arr);<\/code><\/pre>\n
and a corresponding call<\/p>\n
    f(var1, var2, <...>, varm, val1, val2, <...>, valn);<\/code><\/pre>\n
a new function overload is synthesized, where the parameter array arr<\/code>\nis replaced with parameters corresponding to the types of the formal\narguments val1, val2 ... valn<\/code>. Then, overload resolution is performed\nas usual with the additional requirement that such synthesized overloads\nhave lower cost than a C-style variadic function (i.e., those using\n...<\/code> as the last argument) but higher cost than non-synthesized\noverloads. This requirement is in fact the cause of surprising behavior\ndescribed below.<\/p>\n
Customer Reports Previously Working Code is Broken<\/h2>\n
In .NET Framework, the String<\/code> class has these methods (type names\nare from namespace System<\/code>):<\/p>\n
      Split(...array<Char>^);               \/\/ 1 (parameter array overload)   \r\n      \/\/ other Split overloads not of interest<\/code><\/pre>\n
Given a function call such as:<\/p>\n
      str->Split(L'a', L'b');               \/\/ 2<\/code><\/pre>\n
the Split<\/code> overload (2) with the parameter array argument is the only\none that matches. When this same code is compiled against .NET, a\ncustomer found that a different overload is instead chosen. The reason\nis subtle, surprising and a combination of questionable overload\nresolution rules in ECMA-372 and changes to the String<\/code> class in .NET.<\/p>\n
The difference between .NET Framework’s\u00a0version of String<\/code> and .NET’s version is that .NET added an additional overload, leading\nto this set of overloads:<\/p>\n
      Split(Char, Int32, StringSplitOptions = StringSplitOptions::None); \/\/ 3\r\n      Split(...array<Char>^);                                            \/\/ 4          <\/code><\/pre>\n
Now faced with the same function call (2) above, we see that both\noverloads are viable because C++ has an implicit Char<\/code> (aka wchar_t<\/code>) to\nInt32<\/code> (aka int<\/code>) conversion, and the third parameter of (3) has a default\nargument. Due to the rule in ECMA-372\/14.6, the parameter array overload\n(4) is deemed to have a higher cost and overload (3) is chosen, even\nthough the arguments match the parameters exactly for overload (4)<\/em>.\nThis is clearly not what the user wanted.<\/p>\n
Microsoft C++ Solution<\/h2>\n
After discussion in the team, we noticed that there is a telling comment\nin ECMA-372\/14.6 regarding preferring non-synthesized to synthesized\noverloads:<\/p>\n
“[Note<\/em>: This is similar to the tiebreaker rules for template\nfunctions and non-template functions in the C++ Standard (\u00a713.3.3).\nend note<\/em>]”<\/p><\/blockquote>\n
While the tie-breaking rule in ISO C++ does indeed exist, it comes into\nplay only after overload resolution is done and the choice is between\ntwo overloads, one a generated function and one a non-template\nfunction<\/em>. It looked like the ECMA-372 rule for choosing non-synthesized\nover synthesized was poorly formulated as it assigned the latter a\nhigher cost regardless of the costs of the conversion sequences of the\narguments.<\/p>\n
In ISO C++, an analogous example would be:<\/p>\n
    template<typename T>\r\n    void Split(T, T);               \/\/ 5\r\n    void Split(wchar_t, int);       \/\/ 6<\/code><\/pre>\n
The function call Split(L\u2019a\u2019, L\u2019b\u2019)<\/code> will resolve to overload (5) since\nthe arguments match exactly while one of the arguments of (6) requires a\nstandard integral conversion. Hence, there is no need to use the\ntie-breaking rule at all. Were both formal arguments of (6) of type wchar_t<\/code>, the\ntie-breaking rule would indeed come into play and choose (6) instead of\ngiving an ambiguity error.<\/p>\n
It became clear that ECMA-372\/14.6 should have said if there is an\nambiguity between two remaining overloads, one a synthesized parameter\narray overload, and one a non-synthesized overload, overload resolution\nwould choose the non-synthesized one. We decided to implement this\nupdated interpretation but there was a problem: what to do about the\ncode currently compiling and working correctly with the older rules?<\/p>\n
The risk of breaking older code was too great if we went unconditionally\nwith the new rules, so we added two mechanisms to control this behavior\nat the compilation unit level, and whenever needed, at the function-call\nlevel.<\/p>\n
First, we introduced new driver switches:<\/p>\n\n\n\n\n\n\n
<\/th>\n<\/th>\n<\/tr>\n<\/thead>\n
\/clr:ECMAParamArray<\/code><\/td>\nTurn on ECMA-372 conformant parameter array behavior<\/td>\n<\/tr>\n
\/clr:ECMAParamArray-<\/code><\/td>\nUse updated semantics for parameter arrays<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
In addition, the below existing driver switches were changed to imply these\ncorresponding modes:<\/p>\n\n\n\n\n\n\n
<\/th>\n<\/th>\n<\/tr>\n<\/thead>\n
\/clr<\/code><\/td>\nimplies \/clr:ECMAParamArray<\/code><\/td>\n<\/tr>\n
\/clr:netcore<\/code><\/td>\nimplies \/clr:ECMAParamArray-<\/code><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
In plain language, for compilations targeting .NET Framework, we\nmaintain the old behavior, while for compilations targeting .NET, the\nnew behavior is the default.<\/p>\n
To allow fine-grained control over the parameter array overload\nresolution mode at the function-call level, we provide a new pragma,\necma_paramarray<\/code>, which can be used thus:<\/p>\n
    #pragma ecma_paramarray(push, on)\r\n        \/\/ Normally calls Split(Char, int32, StringSplitOptions = None) and\r\n        \/\/ not Split(...array<Char>^) under \/clr:netcore but this is\r\n        \/\/ reverted back to the old behavior under the pragma.\r\n        auto r = s->Split(L'a', L'b'); \r\n    #pragma ecma_paramarray(pop)<\/code><\/pre>\n
This pragma overrides any ambient mode for handling parameter array\noverload resolution, whether it comes from a prior pragma use or from\nthe translation unit’s ambient mode.<\/p>\n
To warn about changed behavior in overload resolution, a new warning\nC5306<\/code> has been implemented. Consider compiling the below under \/clr:netcore<\/code>:<\/p>\n
int main()\r\n{\r\n    System::String^ s = \"Now is the time+for all good men|to come to the aid of the party\";\r\n    auto strings = s->Split(L'|', L'+');  \/\/ Split(params char[]), not Split(char, int, System.StringSplitOptions = 0)\r\n}<\/code><\/pre>\n
This produces the diagnostic:<\/p>\n
    auto strings = s->Split(L'|', L'+');  \/\/ Split(params char[]), not Split(char, int, System.StringSplitOptions = 0)\r\n                      ^\r\nw.cpp(4,23): warning C5306: parameter array behavior change: overload 'System::String::Split' resolved to 'array<System::String ^> ^System::String::Split(...array<wchar_t> ^)'; previously, it would have resolved to 'array<System::String ^> ^System::String::Split(wchar_t,int,System::StringSplitOptions)'. Use \/clr:ECMAParamArray to revert to old behavior<\/code><\/pre>\n
In addition, missing the L<\/code> prefix for arguments can also produce\nsurprising results in overload resolution with the new parameter array\noverload rules. A new warning C5307<\/code> was implemented to warn about\nthis:<\/p>\n
int main()\r\n{\r\n    System::String^ s = \"abc def\\tghi\";\r\n    \/\/ Resolves to Split(System.Char, System.Int32, System.StringSplitOptions = 0) but should warn with C5307\r\n    auto arrs = s->Split(' ', '\\t');  \/\/ Should be Split(L' ', L'\\t').\r\n}<\/code><\/pre>\n
produces<\/p>\n
    auto arrs = s->Split(' ', '\\t');  \/\/ Should be Split(L' ', L'\\t').\r\n                   ^\r\nw.cpp(4,20): warning C5307: 'array<System::String ^> ^System::String::Split(wchar_t,int,System::StringSplitOptions)':\r\nargument (2) converted from 'char' to 'int'. Missing 'L' encoding-prefix for character literal?<\/code><\/pre>\n
Conclusion<\/h2>\n
We would be happy to hear back from you if you have encountered\nproblems in this area and how you solved them, and if the new way of\nhandling parameter array overloads has helped you or hindered you.<\/p>\n","protected":false},"excerpt":{"rendered":"
Fix a problem in C++\/CLI parameter array overload resolution which affects newer .NET versions.<\/p>\n","protected":false},"author":67691,"featured_media":35994,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[86],"class_list":["post-35772","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cplusplus","tag-ccli"],"acf":[],"blog_post_summary":"
Fix a problem in C++\/CLI parameter array overload resolution which affects newer .NET versions.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts\/35772","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/users\/67691"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/comments?post=35772"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts\/35772\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/media\/35994"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/media?parent=35772"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/categories?post=35772"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/tags?post=35772"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}