re: Optional Modifiers and Overload Resolution

Thomas Danecker — Wed, 05 Mar 2008 19:42:46 GMT

It should be noted that there's also a modreq (required modifier) that "indicates that there is a special semantics to the modified item that should not be ignored, while an optional modifier can simply be ignored." -- ECMA-335 (CLI), Partition II, 7.1.1

To the topic:

I again do not like such kind of overload resolution. Just issue an error and force the user to resolve the ambiguity! Do not even try to resolve it automatically! There is a user compiling the code with whom the compiler can interact. Don't be always so afraid of asking this user what to do if you (the compiler) don't have a clue what he exactly intended to do.

The problem I'm noticing here is that the programmer currently can only resolve the ambiguity by modifying the called code but not by modifying the calling code. Another possibility is to switch to another language whos compiler is able to select the method intended to call and building a wrapper callable by c#. This of course violates one goal of the CLI - being language-independent, but on the other hand, if using modopt or modreq, it's clear that the produced code isn't intended to be fully language-independent.

To resolve the issue, Greg Young's suggestion is quite reasonable - if the implementation is embedded in the general handling of types and not only in the heuristic of overload resolution.

So IMO, the compiler should not silently but noisily pass on modopts. Build clear semantics into the language:

Types with different or no modopts are assignment compatible.

Types with different or no modreqs are not.

Overload resolution should keep its paradigm: Best match. A type with modopts matches better to the equal type with a subset (or none) of these modopts than to the equal type with a different set of modopts. Having only equal types with different sets (or supersets) of modopts available should issue an error.

So now, the type with the minimal number of modopts won't win until its set of modopts are a subset of the parameter's type's set of modopts.

Something is still open: How to represent types with modopts in the language?

.class public auto ansi beforefieldinit Modopt

extends [mscorlib]System.Object

{

.method public hidebysig instance void

Foo(int32 x) cil managed

{

...

} // end of method Modopt::Foo

.method public hidebysig instance void

Foo(int32 modopt([mscorlib]IsConst) x) cil managed

{

...

} // end of method Modopt::Foo

.method public hidebysig instance int32 modopt([mscorlib]IsConst)

Bar() cil managed

{

...

} // end of method Modopt::Bar

...

} // end of class Modopt

Now,

var x = Bar();

Foo(x);

would resolve to the second method because the type of x is int32 modopt([mscorlib]IsConst).

int x = Bar();

Foo(x);

would resolve to the first method.

It would be nice to also be able to specify a type with modopts/modreqs explicitly. Maybe something like the following may fit into the language:

int modopt(System.Runtime.CompilerServices.IsConst) x = Bar();

Foo(x);

That's how I think it should be done. Sorry if I sounded a little bit harsh, but I really love C# and the .net Framework. Hopefully you appreciate my feedback.

By the way, here's Greg Young's feedback leading to this blog post: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=282405

I'll also post this there.

re: Optional Modifiers and Overload Resolution

ildjarn — Fri, 07 Mar 2008 00:46:03 GMT

Re: "ie C++ does not allow you to distinguish methods only by their const-ness", actually VC++ 2008 lets me generate this without much complaint:

.class public auto ansi beforefieldinit CFoo

extends [mscorlib]System.Object

{

.method public hidebysig specialname rtspecialname instance void .ctor(int32 x, int32 y) cil managed

{

...

}

.field public int32 X

.field public int32 Y

}

.class public auto ansi beforefieldinit CBar

extends [mscorlib]System.Object

{

.method public hidebysig specialname rtspecialname instance void .ctor() cil managed

{

...

}

.method public hidebysig instance int32 Foo(class Baz.CFoo foo) cil managed

{

...

}

.method public hidebysig instance int32 Foo(class Baz.CFoo modopt([mscorlib]System.Runtime.CompilerServices.IsConst) foo) cil managed

{

...

}

Community Convergence XLI

Charlie Calvert's Community Blog — Wed, 12 Mar 2008 00:35:44 GMT

Welcome to the forty-first Community Convergence. The big news this week is that we have moved Future