Breaking changes and named arguments

re: Breaking changes and named arguments

Alan Pretre — Fri, 30 Dec 2011 15:23:27 GMT

It appears there is a bug in C# 4.0 with named arguments and struct members passed by reference:

connect.microsoft.com/.../evaluation-of-named-by-ref-arguments-in-c

re: Breaking changes and named arguments

Alex — Thu, 08 Dec 2011 19:27:53 GMT

Slightly off topic, but I recently noticed that the use of named parameters has a noticable performance impact. What is the reason for that? Aren't optional and named parameters just caller side "compiler sugar"?

Named and optional arguments can cause the compiler to introduce temporary varibles (to ensure that the side effects of argument computation happen in source code order, not in the order in which the arguments are put on the stack for the call.) Introducing extra temporaries can sometimes cause the jitter to generate less optimal code. I don't know of any other specific situation though; can you give me an example? -- Eric

re: Breaking changes and named arguments

NB — Tue, 15 Nov 2011 06:37:06 GMT

@Gabe - No, I think I prefer named parameters to defining wrapper classes/structs for all different parameter kinds. Seems to me they achieve pretty much the same in a generic way and without overhead as well. They might perhaps not be as powerful but I think I can live with that.

re: Breaking changes and named arguments

Gabe — Mon, 14 Nov 2011 18:37:04 GMT

DRBlaise: Yes, it is much better to always create a wrapper class for every parameter type that is duplicated in any method call. That way rather than having something ridiculously confusing like

CopyFile(SourcePath: srcPath, SourceFilename: srcFile, DestPath: dstPath, DestFilename: dstFile);

you can have the much clearer

CopyFile(new SourcePathName(new Path(srcPath), new Filename(srcFile)), new DestPathName(new Path(dstPath), new Filename(dstFile)));

right?

Sure, it requires extra typing, the creation of 4 wrapper classes, and additional overhead of memory allocation, wrapping calls, unwrapping calls, and garbage collection. But it's all worth it because, even though the wrapper classes' names can't ever change and the user of a method can't put the arguments in the order that makes sense in context, the method parameter names can be changed on a whim, right?

Besides, you can just make the wrapper types structs to avoid the memory allocation and GC overhead, and hopefully your JIT will inline the wrapping/unwrapping calls you make. So really only the person writing the method and the person calling the method would have to pay for the overhead; the person running the code should be largely unaware of the wrappers so long as they don't notice the extra disk space, memory usage, and JIT time that the wrappers add.

Of course if you're using a language like Java, you don't have structs, so each type has to be a class that requires memory allocation (though maybe the JIT can optimize that out?), and each wrapper class requires not only its own source file but also its own object file.

re: Breaking changes and named arguments

DRBlaise — Mon, 14 Nov 2011 15:02:34 GMT

@Gabe - As PleaseDontLowerCSharpQualityBar points out, the clarity of of named parameters is only valid when you make a poor design choice in the creation of your method parameters. If you go with the best design practice of never having 2 method parameters of the same type, then you avoid the need of named parameters.

If the CalculateMotion method was defined as void CalculateMotion(Postion position, Velocity velocity, Acceleration acceleration) then there would be no problem.

Just like you should never use bool as a parameter of a method, you should really never use double, int, string, etc. as they don't specify the MEANING of the parameter. Always create a wrapper class that specifies the meaning of the parameter, and you can avoid the need for named parameters.

re: Breaking changes and named arguments

Gabe — Mon, 14 Nov 2011 04:56:22 GMT

One of the great uses for named parameters is for making it clear what parameters you're passing. For example,

CalculateMotion(velocity: aircraftVelocity, position: aircraftPosition, acceleration: aircraftAcceleration);

is obviously correct, while

CalculateMotion(aircraftVelocity, aircraftPosition, aircraftAcceleration);

requires looking at the documentation or the declaration of CalculateMotion to tell if it's correct.

re: Breaking changes and named arguments

UseTheRightToolForTheJob — Fri, 11 Nov 2011 18:14:14 GMT

Tergiver: if you like a more verbose syntax (with "and" instead of "&&", etc.) then you can use VB.

re: Breaking changes and named arguments

Tergiver — Fri, 11 Nov 2011 15:44:29 GMT

Named parameters are a great feature to help make code more readable.

Now when are the C# authors going to finally get around to implementing ISO646 in C#? C and C++ have had it for a very long time: www.cplusplus.com/.../ciso646

While I personally don't use the named operators for bit operations, I much prefer

if (ready and enabled)

if (ready && enabled)

Oh right.. it's too late. It would now be a breaking change to the language =(

re: Breaking changes and named arguments

Shawn Hargreaves - MSFT — Thu, 10 Nov 2011 20:28:21 GMT

> But now with this new C# 4 feature you introduced a breaking change: I must be bothered with parameter names.

You are making two conflicting arguments at the same time:

1) "This is a breaking change because it forces me to bother with parameter names."

2) "It did not use to be a breaking change because I chose not to care about VB developers or people using reflection."

If you are in a position where you can selectively choose to ignore things, why not choose to ignore named parameters, just the same as you already chose to ignore VB and reflection users? Or if you are in a position where you have to make things work for all possible consumers of your library, then you already had to bother with parameter names, for the reasons already given. You can't have it both ways.

> Eric> Professional VB developers are an enormous market and have been for almost two decades now.

> I don't agree with that, and that is based on my experience, probably different from yours.

This has nothing to do with subjective personal experiences. The size of the VB developer market is easily quantified by counting the number of VB developers who exist in the world. If you do that, you will find it is a very large number.

re: Breaking changes and named arguments

PleaseDontLowerCSharpQualityBar — Thu, 10 Nov 2011 10:26:42 GMT

hype8912> I've never found a use for this capability to begin with. It just makes the calling string that much longer.

Consider this case:

// #1 - named arguments

new StreamWriter(

path: filename,

append: true,

encoding: someEncoding

)

// #2

new StreamWriter(

filename,

true,

someEncoding

)

#1 uses named arguments, and IMHO is too much verbose.

The only semantic information added by #1 and kind of lacking in #2 is about the append mode.

But the problem here is due to an unfortunate design decision in the StreamWriter constructor prototype.

In fact, instead of using a bool, I'd have used a descriptive enum to specify append vs. overwrite mode.

If an enum was used in this case, named arguments would have added nothing, because we'd have read some "append" in the calling code, instead of the more opaque 'true'.

Another example that some people consider in favor of named arguments is for methods taking several parameters.

But IMHO it is a design horror: if a method has too much parameters, this may be a red flag, and some refactoring may be needed. For example:

void CalculateMotion(

double positionX, double positionY, double positionZ,

double velocityX, double velocityY, double velocityZ,

double accelerationX, double accelerationY, double accelerationY

)

is a coding horror. The double's should be better packed in a more meaningful Vector3 class, and the method refactored something like this:

void CalculateMotion(

Vector3 position,

Vector3 velocity,

Vector3 acceleration

);

And then, when argument names are choosen carefully, there is no need to repeat the parameter names:

CalculateMotion( aircraftPosition, aircraftVelocity, aircraftAcceleration );

is just better then:

CalculateMotion(

position : aircraftPosition,

velocity: aircraftVelocity,

acceleration: aircraftAcceleration

);