Ttyjukl

Be humble.

I'm a bit confused here. My understanding was that feature X has property Y. Is there something I'm missing here which means this doesn't work in this case?

Much better to start from the assumption that you are the one that is wrong, rather than the other way round. If you're wrong, you'll learn something; if you were in fact right, you've now taught your manager something in a non-confrontational way.

As an important aside, while you say this is different from our other question, it isn't really: you should be humble with your peers and with your juniors as well.

You can simply "ask for more clarity" and show willingness to change but subtly indicating that his concerns are not valid. An email to this effect may help:

You have requested following changes in the code because of so and so reasons. However, my understanding of this language is that this problem will not occur because it instead works this way. I suppose I am missing something but could you please clarify or confirm that my understanding is wrong? If you have few minutes, I can show a demo of this and may be you can point out more specifically what your concerns are.

This way you will at least have a documented proof that you tried to correct him back. If he still insist, you can do whatever he requested and just hope it wont be a problem in the long run.

In one of your comment you say:

"it is trivial to conclude that the requested change has no effect"

Based on this, the easiest way forwards would be to keep the change and spend your energy on something more important.

Obviously this is only applicable if the change is indeed harmless.

If your manager gets this part of the language wrong, is it possible that other developers will also be confused by it? Bear in mind that maintainability by other people should be a goal. So: if this feature is confusing, there's an argument to be made for not using it.

With that in mind, you can go to your manager and -- being humble -- state that
you were surprised by his comment, and so you double-checked the documentation. It turns out that this feature is as you described, but you accept that it could be confusing, so you agree that you'll adopt his suggested clearer way to write the code.

I feel that Philip Kendall answer is incomplete and lacking some backup so that is why I decided to write my own.

I often struggle to make people understand that they said something false but here are some techniques that often works for me:

Technique One

If someone makes an unsupported claim that I'm afraid is false, I ask them for backup. Like:

Oh, this is interesting/disturbing/curious, do you have any source for that? I want to know more about it.

Then, I let them search and they will, hopefully, realize their mistake on their own. Since they are the one who realize their mistake, they won't feel the shame that often come with the fact of being corrected.

If this doesn't work, I use technique two.

Technique Two

If the previous technique didn't work or isn't possible, I act confused and ask for clarification. This way, I'm showing that I'm open to the possibility of being wrong myself and that being wrong isn't such a big deal.

I usually start with some basic questions and then ask the more complex ones, like:

Me: So, <some basic question>, right?

Other: Yes

Me: And, <some other basic question>, right?

Other: Yes

Me: So, knowing that, why do you say that <your real question>?

Using this series of question allows you to be sure that you are on the same ground knowledge and that you don't have some misunderstanding somewhere.

When they answer your last question, if you are still not satisfied with their answer, you can ask follow up questions, like:

I still don't understand. When I read X, I understand Y. Isn't this right?

You notice that, during the conversation, I keep blaming myself for the misunderstanding. By doing so, you are not pressuring the other to be right. Since you can acknowledged being wrong with no shame, they will be more at ease to do the same.

I use this technique often and, so far, it's the best I have. Note that, in my experience, heated arguments are really bad and should be avoided at all cost.

I would handle it in two ways, depending on the supervisor.
If the supervisor is a tech person that works in the language you code in - I would contact them through an email with something along the lines of:

During the last code review, you have commented part xyz of my code as invalid and it got me wondering if my knowledge of how it works was correct. I have checked against the
documentation and made a small demo application and it seems to work correctly - should I still make the change or keep it in the current version?

Do include links to the documentation about that code part and a small demo - most developers, both junior and senior, are eager to learn new things in the field they work in and there is always a chance that it was just an honest mistake of your supervisor. It also shows that you make sure the knowledge you use at work is correct, which is usually well received by supervisors, while not attacking the supervisor in any way.

If your supervisor does not work with the language you use (as some teams often use many different technologies and the supervisor has to learn them a little for the sake of code review), and as you mentioned it is not a big change, I would change the code and not address it further - trying to persuade that your version is correct and their knowledge is too small would probably create more tension and negative feelings between you and your supervisor, than it would create good language practices.