Resolve naming conflicts with Objective-C++

[xiaozhuai]

Dear @max0x7ba

My apologies for reopening this PR.
First of all, hope you have a good day!

Although I could have just left these changes sitting quietly in my fork, I decided to try submitting a PR again.
I just hope more people will benefit from your excellent‌ work.
I completely agree with your point that one PR should focus on just one thing.
And this time I don’t want to talk about how beneficial this PR is, because I understand you might not be interested in Objective-C++ compatibility at all.
So, I’d like to talk about what side effects this PR might bring.

1. Is this a breaking api change?
   nil is inside details namespace. So we don’t want users to use it, and we don’t guarantee the consistency of this, am I right? So the answer is NO.

2. Will this increase maintenance complexity?
   Obviously NOT, this is a one-time change.

3. Does this violate the principle that this library was designed for C++?
   IMO the answer is NO. We just achieved zero-cost compatibility with Objective-C++ while prioritizing C++ support.

Of course, I respect your decision, and I won’t submit any similar PR in the future if this one is rejected.
Finally, I still hope this PR can be merged into the upstream.
And thank you again for your excellent work.

[max0x7ba]

Dear Weihang,

I do not mind renaming nil function at all. However, you do that for compatibility with Objective-C++, but there is no continuous integration set up for the OS with Objective-C++. Any commit may unwittingly break compatibility with Objective-C++ , and we'll never notice such a regression with no continuous integration for Objective-C++.

I make changes and test them locally on x86_64 Linux only. Portability/compatibility for different OSs and CPUs is maintained by the continuous integration only, it is the only thing preventing commits from breaking builds on platforms it is set up for.

If you'd like compatibility with Objective-C++ to be established and maintained, you should set up continuous integration for Objective-C++ first. With that set up, we'll be able to see/refer the exact same thing/issue and test proposed solutions/PRs.

PRs that fix something somewhere for someone without any means to confirm the issue and verify the proposed solution is the opposite of the best development practices which enabled this library to be robustly portable in the first place.

Does this make sense to you, Weihang?

Maxim

[xiaozhuai]

Sure, I will add CI support for the macOS platform.