More on modopt

Previously I discussed some issues with modopt. Well there are more. In total I have logged three issues (could be many more as nearly every language I have looked at has the same problems). I figured I would put up some links and describe each issue here.


 C# specification does not define modopt varying overloads in its best match algorithm


From 335 (7.1.1): “Two signatures that differ only by the addition of
a custom modifier (required or optional) shall not be considered to
match.”


There is no mention of C#’s behavior when dealing with these overloads.


C# if given an overload based upon modopt will always select the version without the modopt. I would consider this to be part of its overload best match seeking algorithm.


https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=282404


Generics do not support modopt


Generics do not properly support modopt generation when a modopt is included in a type paremeter. As an example:


class A<T> {
    public foo(T t) {
        Console.WriteLine(t.ToString());
    }
}

A<modopt(foo) string> a = new A<modopt(foo) string>();


the type created by the CLR will be of type A<string> not A<modopt(foo) string>. These items are deemed by the CLR (quote above) to be non-equivalent and will often times have different behavior associated to them by a compiler or by runtime code.


https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=282406


Suggestion to change C# modopt overloading


in something else that can generate modopts …
public void PutSomething(string modopt(Foo) something);
public void PutSomething(string something);
public string modopt(Foo) GetSomething();



in C#
PutSomething(GetSomething())


This call will generate a call to PutSomething(string) even though the value being returned from the library is a string modopt(Foo). C# can logically determine to call the modopt included overload here regardless of if it understands the modifier or not as the library returning it the value obviously does support the modopt.


https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=282405


 


 


All in all this seems to be a very obscure area of the spec that was never taken into heavy consideration when designing many things and as such has alot of bugs associated with it.

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

7 Responses to More on modopt

  1. Yep, modreq seems to be the same. C# can call this C++ method:
    int function(int % argument)
    but not this:
    int function(volatilve int % argument)
    which emits the following IL:
    .method public hidebysig instance int32 function(int32 modreq([mscorlib]System.Runtime.CompilerServices.IsVolatile)& argument) cil managed

    …whose only difference is the modreq…

  2. Greg says:

    Interesting to know Don. Just one question per “by design” if modopts havn’t had support added my guess would be modreq doesn’t either (since it would be identical). What does this mean for generics and language interop?

  3. Don Syme says:

    Hi Greg,

    I’ve been following your blog – good to see you’re looking at this.

    FWIW the behaviour w.r.t. generics is by design – we decided to ignore custom modifiers in instantiations, mostly to simplify the implementation (generics almost didn’t make it in to the product because it was almost deemed “too much work”). I agree it would be interesting to allow it.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>