Shadowed Member in merge_patch

[ax3l]

• What is the issue you have?

Compiling in downstream projects with -Wshadow warns on void merge_patch(const basic_json& patch) shadowing a member of this.

https://github.com/nlohmann/json/blob/master/include/nlohmann/json.hpp#L7866

• Please describe the steps to reproduce the issue. Can you provide a small but working code example?

Compile with Clang 5.0.0 and CXXFLAGS="-Wshadow".

• What is the expected behavior?

Better not to shadow a member of this :)

• And what is the actual behavior instead?

Throws a warning, e.g.: https://travis-ci.org/openPMD/openPMD-api/jobs/449795263

single_include/nlohmann/json.hpp:
In member function ‘void nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType, JSONSerializer>::merge_patch(const nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType, JSONSerializer>&)’:
single_include/nlohmann/json.hpp:20126:5: error: declaration of ‘patch’ shadows a member of 'this' [-Werror=shadow]
     {

• Which compiler and operating system are you using? Is it a supported compiler?

Clang 5.0.0 on Travis CI (Ubuntu 14.04)

• Did you use a released version of the library or the version from the develop branch?

We use release 3.4.0.

• If you experience a compilation error: can you compile and run the unit tests?

N/A

first seen by @franzpoeschel

[nlohmann]

Thanks for reporting. I do not like such warnings, because in the end they make the code "uglier", because I think it is fine to both have a member function called patch and a function parameter patch. But I think one can fix this by changing the parameter name to p or something...

[ax3l]

Thanks for your feedback! Yes, I know that this "uglifies" the code a little by e.g. introducing consequent prefixes for members or the like in most cases... But I also got bitten quite a bit by shadowed vars in the past in large projects which are hard to catch sometimes.

If you are ok with that, I would really just rename the parameter name: #1346