Consider new keyword "methodname"

[The-Futurist]

How do people feel about a new keyword "medthodname" - where this is replaced at compile time with the name of the containing method.

Motivation here is that when we copy/paste some method several times that contains a nameof(original_method_name) it's easy to overlook and leave the copied methods name inside the nameof.

Thoughts...

[YairHalberstadt]

Why stop there? Why not classname, propertyname, eventname, namespacename etc?

Also how would this be resolved inside a local method? The innermost method, or the outermost?

I think the point I'm trying to make here is that there an infinite number of cases where C# could add a feature to help in one specific use case. But with limited time available to the team, and little spare capacity for students of the language to learn yet another syntax and it's rules, you have to make the case as to why this is so important it makes the cut.

I'm not saying this is a bad idea. I'm just asking for a stronger case as to why this is so important it's worth special casing the language for. Have you explored other options like using a Roslyn analyser to warn you when you make a mistake?

[ghost]

Perhaps the CallerMemberNameAttribute would work for you?

[theunrepentantgeek]

A language change doesn't seem to be worthwhile, when you can do this with a simple helper method:

private string MethodName([CallerMemberName] string name = null) => name;

[john-h-k]

Motivation here is that when we copy/paste some method several times that contains a nameof(original_method_name) it's easy to overlook and leave the copied methods name inside the nameof.

If you're copy-pasting the same method several times you've got a problem already. Secondly, the nameof will be unable to find the method name in the copied over method and give you a nice error that's easily fixable for you. Thirdly, I'm gonna say it again, copying and pasting methods over the place is a code smell, particularly if you're doing it often enough to worry about refactoring nameofs.

[YairHalberstadt]

Thirdly, I'm gonna say it again, copying and pasting methods over the place is a code smell, particularly if you're doing it often enough to worry about refactoring nameofs.

Maybe, but refactoring is full of Cut and Pastes. Refactoring tools can help, but sometimes nothing beats a good ol' ctrl-x, ctrl-v.

[john-h-k]

@YairHalberstadt of course; but if it's at the point where this is a serious issue, you're doing it too much. It's the JITters job to inline the methods, not the devs 😛. Unless you've got a million nameofs and a text editor with no find and replace this would never be a major issue imo

[The-Futurist]

Motivation here is that when we copy/paste some method several times that contains a nameof(original_method_name) it's easy to overlook and leave the copied methods name inside the nameof.

If you're copy-pasting the same method several times you've got a problem already.

@johnkellyoxford

I don't have a problem "already" this is a growing family of methods that share a common pattern which includes writing a log message (containing their names). The fact that I initially create the method by copying another is nothing unusual.

Secondly, the nameof will be unable to find the method name in the copied over method and give you a nice error that's easily fixable for you.

Except for the fact that your quite wrong - MethodB can contain the expression nameof(MethodA), this is quite legal C# and there's no scope for a compilation error, in this case the methods are all in the same class (they are interface implementations), you seem to be assuming lots of things that are simply untrue, all you need to do is ask me, don't blindly assume.

Thirdly, I'm gonna say it again, copying and pasting methods over the place is a code smell, particularly if you're doing it often enough to worry about refactoring nameofs.

Copying and pasting source code is extremely common, of course cloning and repeating logic is undesirable but that isn't what I did you have assumed that and once again you are in error.

The bottom line here is simply to see if C# can be updated to help us refer to the name of the containing method rather than currently having to explicitly refer to that containing method.

How these methods come into existence is immaterial, all you need do is consider a class that exposes multiple methods where each method needs to pass its own name (say to a logger).

[john-h-k]

@Korporal so you have a very large number of methods all doing similar things in the same class (otherwise nameof(otherMethod) wouldn't be legal)? Why don't you just create a log function that takes CallerMemberName?

 this is a growing family of methods that share a common pattern

To me, this sounds like a fancy way of getting around saying "I have lots of code duplication". If they're all logging their names use CallerMemberName and a separate log function.

[The-Futurist]

@Korporal so you have a very large number of methods all doing similar things in the same class (otherwise nameof(otherMethod) wouldn't be legal)? Why don't you just create a log function that takes CallerMemberName?

this is a growing family of methods that share a common pattern

To me, this sounds like a fancy way of getting around saying "I have lots of code duplication". If they're all logging their names use CallerMemberName and a separate log function.

@johnkellyoxford

I don't care how it sounds to you. You cannot evaluate the efficacy of something without seeing it, you have not seen the source code in this case have you? No you have not so please stop implying that you can assess code quality without seeing said code.

[john-h-k]

It just seems a very trivial operator when it's so easy to nameof your current method. If you're copy and pasting then you've gotta be prepared to refactor slightly. Every decent text editor has a find and replace, which can easily fulfil this function without the need for a new keyword (a breaking change, bad)

[HaloFour]

@korporal

I don't have a problem "already" this is a growing family of methods that share a common pattern which includes writing a log message (containing their names). The fact that I initially create the method by copying another is nothing unusual.

You've just described one of the primary use cases of CallerMemberName. The name is then embedded as a literal to the method call. It requires less code on your part and is as efficient as it gets. There's no reason to add an inferior duplicate of that feature.

[CyrusNajmabadi]

I don't care how it sounds to you. You cannot evaluate the efficacy of something without seeing it, you have not seen the source code in this case have you? No you have not so please stop implying that you can assess code quality without seeing said code.

You're the one asking for this operator. The onus is on your to present a compelling enough case to justify it. That includes providing enogh information and justification to offset how this sounds to people when you make these statements.

[CyrusNajmabadi]

How these methods come into existence is immaterial, all you need do is consider a class that exposes multiple methods where each method needs to pass its own name (say to a logger).

This is already a solved problem. You can use CallerMemberName to pass this info to, say, a logger. If this is insufficient, you need to clarify what is missing and why you need it.