[gnud]

c# already has the 'chained' API in the standard library:

    new FileInfo(srcPath).CopyTo(dstPath)

On the other hand, it also has the more error-prone

    File.Copy(sourceFileName,destFileName);

[Lio]

I know nothing about C# so please pardon my ignorance but how does:

  new FileInfo(srcPath).CopyTo(dstPath);

provide more protection vs

  CopyFile(src: srcPath, dest: dstPath);

Assuming that both path strings are set correctly isn't a typo here going to cause the same error and be just as visible?

e.g.

  new FileInfo(pathA).CopyTo(pathB);
  CopyFile(src: pathB, dest: pathA);

neither would seem to show which is correct without knowing what the path values are if the variable names are ambiguous.

[gnud]

When using the FileInfo api, it's obvious which argument is the source and which argument is the destination. When using the CopyFile, it's not.

If you can't keep track of your variable names, then using keyword arguments, like others here talk about, won't help much, either.

[Lio]

Sorry, not sure if your parent was edited to remove keynamed parameters from the second example or if I've responded to the wrong comment.

I'd definitely agree with you that the not having named arguments is worse than your method chained example.

To me named parameters seem to be on a par with the chained OO api.

[gnud]

Ah, the reason is simple: C# allows named parameters, but do not enforce them. You can call File.Copy both as

    File.Copy(a,b)

and

    File.Copy(sourceFileName: a, destFileName: b)

And confusingly, also as

    File.Copy(destFileName: b, sourceFileName: a)

[Lio]

OK I see. That explains it and also gives a very concrete reason for using the chained API. Thanks.