Jon Skeet: Coding Blog

MY GOD! IT'S FULL OF STARS!

I haven't read the spec yet but I think it does make perfect sense. I expected named parameters to be resolved statically. The question is: what happens with "dynamic dy = d; dy.Foo(x:10, y:20);"?

This is a nice one for a C# exam ;)

Just kidding ofcourse.

When you use dynamic, it gives you x=20, y=10 for both, when you rename the parameters, it comes clear why this is like it is :)

Derived d = new Derived();

Base b = d;

d.Foo(xx: 10, yy: 20);

b.Foo(x: 10, y: 20);

Otherwise, it won't compile

Nemerle also supports named parameters and came to the same conclusion about how this should work:

using System

class Base

   public virtual Foo(x : int, y : int) : void

       Console.WriteLine($"Base: x=$x, y=$y")

class Derived : Base

   public override Foo(y : int, x : int) : void

       Console.WriteLine($"Derived: x=$x, y=$y")

class PureEvil

   static Main() : void

       def d = Derived()

       def b = d : Base

       b.Foo(x=10, y=20)

       d.Foo(x=10, y=20)

@Jon: Having read the spec, I think your expectation is true. The `dynamic` version would behave similarly. RE Resolving top to bottom: Yes it could have done that but IMO, that would be weird. I think when a class "overrides" a method, it *swaps* the whole thing with its own and the overridden version becomes its member, not the original member. By the way, I just wanted to note that this is not a new thing. .NET framework has always behaved like this: `typeof(Derived).GetMethod("Foo").GetParameters()[0].Name` will return `y`.

Most likely, this would crop up in real life because of a mistake. The results, then, would be evil even with positional parameters:

Base b = new Derived();

b.Foo (10, 20);   // x=20, y=10

That is so nasty. I would have expected c# to forbid you to rename the arguments.

The question is: Is C# harbouring C++ Complexity Envy. It won't have to for long if MS keeps adding detail-devils like this. Time will tell of course just how many development dollars adding this feature to C# saves the collective software industry, vs. how many it costs in being pure 'bug factory' material.

@Tom, I'm not sure, named parameters can make your code a lot more readable (and Jon will probably agree that readability is key...)

If you end up in such a situation, I think you deserved it because you were asking for it (yet the compiler could prevent renaming parameters when overridding)

It is still a very good case study for those you prefer undestanding rather than knowing

There's one good reason why the compiler can't prevent renaming parameters when overriding: it would break existing code.

I was of course only serious when I made the C++ complexity quip. So far, and I'm hoping Jon can provide the 'light build moment', I'm finding that C# 4 just doesn't "do it" for me in the same way C# 3 did. With luck I'm just being dense and missing all the big value statements. I was kind of hoping C# 4 would including more compiler time help for creating const / immutable structures - but I'm beginning to think that's going to require at least some radical BCL work and most likely CLR changes too.

This really sucks. Why in gods name do we want such a behavior? This makes no sense to me.

I would suggest that they should add a compiler warning for any call site using named parameters where the parameter names involved have changed in the virtual hierarchy.

I thought that the named parameters were only supposed to be 'labels' for the parameters, and not effect behavior at all???

For extra giggles, I find myself wondering what happens if Base, Derived, and PureEvil all live in separate assemblies, and you fiddle with the parameter names in Base and/or Derived without recompiling the other assemblies...

C# devs have historically seemed reluctant to add new warnings, the motivation apparently being that this may break users with "Warnings as Errors" on.  For instance, even obviously unsafe usage of IDisposable classes still doesn't cause a compiler warning (when it really should).

So, if that's really a prime motivation, then adding a warning at the call site may be lower risk to them - after all, you can't break old code that way, since no old code has named parameters _anyhow_.

Code analisys (FxCop) has a rule for this one: "Parameter names should match base declaration" (CA1725)

This rule only checks types with a public access modifier though.

There is nothing nasty about the language here. Only the derived code is nasty.

You can't use the parameter names for Base.Foo when directly calling Derived.Foo. If you have a method with parameters 'foo' and 'bar' it's ridiculous to have to call it with 'blah' and 'zing' just because those happen to be the parameter names in some ancestor of the method. Just think of the confusion this would cause.

You also can't use the parameter names for Derived.Foo when calling Base.Foo, because there is no reason to suppose that Derived.Foo is any better for taking the names of than SomeOtherDerived.Foo. In fact, there might not even be any derived classes.

So you always have to use the parameter names for the method you're calling, regardless of it being virtual or an override or not. Which makes perfect sense.

There is nothing else the language could logically do. It's your code that is evil. And there's a simple solution for that: don't write this code (and who would!) :-)

PS. I don't actually see you saying that the problem is in C# and not your code per se ... in fact I basically see you saying the opposite. But then, why call attention to the obvious fact that even if there's nothing wrong with a language you can still do horrible things in it? I don't understand.

Anyone who has been concerned with interoperability has always considered parameter names to be a part of the public API, given that VB has had named parameters from the beginning. I believe there is a statement about that in the Framework Design Guidelines, although I can't remember where at the moment.

Rather unfortunate that the specifications basicallty breaks Liskov.

If you for some reason renamed the parameters of one of your classes you can no longer make the substitution with out breaking your code.

You might argue that the the developer is breaking the principle by using named parameters (and changing names) but I none the less finds it questionable when the language makes that possible

It's more evil that the parameters on an overridden method were renamed. ;)

I added my +1 to the connect feature

I hope that there is an FxCop rule for this!!

This is something that really bothers me about the optional parameter spec in C# 4.0 - that and the fact that optional values are actually compiled into the callsite, rather than dynamically fetched at runtime from the assembly's metadata and then cached.

C# 4.0 has essentially made the parameter names a weak part of the signature of the method - as far as overload resolution is concerned for optional/named parameters.

I have to say, that I believe that this should be a case where the compiler detects and prohibits the override in the derived class.

In fact, the compiler should enforce that when the override keyword is applied to a method, the argument names must match the base method in both order and name.

It may not be perfect, especially when parameter names can change in the base class over time, or conflict with other overloads - but it's better than changing the overload resolution on the fly based on which version of the framework you compile to - or whether you call the method through a base or derived reference, or through a dynamic reference.

Minimally, the compiler should provide a warning when arguments to a method are renamed in an overriding method, or reordered at a call site.

Happily, this is an unlikely situation. Why would you want to overload a method with another method with the same name, the same number of patameters and their same types?

Overloading is not for this coding evilness!!!