Cannot index by key of type static constexpr const char*

[poskadesign]

This will not compile, error: use of overloaded operator '[]' is ambiguous (with operand types 'json' (aka 'basic_json<>') and 'const char *const'). Code:

static constexpr const char\* _VAR1 = "MyKey";
void foo() {
    nlohmann::json j;
    j[_VAR1] = 10;
}

[nlohmann]

I can confirm the bug for Clang (Apple LLVM version 7.0.2 (clang-700.1.81)) and Clang 3.7:

Code:

#include <json.hpp>

using nlohmann::json;

int main()
{
    static constexpr const char* _VAR1 = "MyKey";

    nlohmann::json j;
    j[_VAR1] = 10;
}

yields:

issue171.cpp:10:6: error: use of overloaded operator '[]' is ambiguous (with operand types 'nlohmann::json' (aka 'basic_json<>') and 'const char *const')
    j[_VAR1] = 10;
    ~^~~~~~
src/json.hpp:2911:15: note: candidate function
    reference operator[](const typename object_t::key_type& key)
              ^
src/json.hpp:2959:21: note: candidate function
    const_reference operator[](const typename object_t::key_type& key) const
                    ^
issue171.cpp:10:6: note: built-in candidate operator[](long, const char *)
    j[_VAR1] = 10;
     ^
issue171.cpp:10:6: note: built-in candidate operator[](long, const volatile char *)
1 error generated.
make: *** [issue171] Error

Interestingly, GCC 5.2.0 works... I shall have a look at this later.

[nlohmann]

This seems related: http://stackoverflow.com/questions/8914986/should-this-compile-overload-resolution-and-implicit-conversions

[nlohmann]

The ambiguity is not really between the const and the non-const version. A different program yields

src/json.hpp:2959:21: note: candidate function
    const_reference operator[](const typename object_t::key_type& key) const
                    ^
issue171_1.cpp:13:15: note: built-in candidate operator[](long, const char *)
    auto x = k[_VAR1];
              ^
issue171_1.cpp:13:15: note: built-in candidate operator[](long, const volatile char *)

[gregmarr]

Is the entire root of the ambiguity this function:

operator value_t() const noexcept
{
    return m_type;
}

which allows a json to be converted to an enum? If so, should that just be removed in favor of the explicit type() function?

[nlohmann]

I'll look into it tomorrow.

[nlohmann]

I removed operator value_t() const noexcept and get the same error.

Then I tried removing operator ValueType() const and the code compiles. It seems to be the same issue as in http://stackoverflow.com/questions/8914986/should-this-compile-overload-resolution-and-implicit-conversions

[nlohmann]

After reading http://clang-developers.42468.n3.nabble.com/Why-doesn-t-this-compile-clang-implicit-conversions-amp-overload-resolution-td3668157.html, I added the constraint and not std::is_same<ValueType, long>::value to operator ValueType() const and the example compiles...

[nlohmann]

It seems like Clang is correct to reject the code, and the only fix I could think of is to forbid an implicit conversion of a json object to long. However, I think the latter usecase is way more common than the issue we try to fix...

In the end, j[_VAR1] = 10; could be replaced by j[std::string(_VAR1)] = 10;.

What do you think?

[nlohmann]

Right now, I am clueless how to fix the issue. As The use case is rather specific, I could live with closing the issue as "won't fix".

[twelsby]

I have a solution for this. It turns out that constexpr and static are irrelevant to the problem, which can be reduced to:

const char* _VAR1 = "MyKey";
nlohmann::json j;
j[_VAR1] = 10;

In addition the following also cause the same problem (c style casts for brevity):

char* _VAR1 = "MyKey";
j[_VAR1] = 10;
j[(const char*)"MyKey"] = 10;
j[(char*)"MyKey"] = 10;

Yet these all work:

char _VAR1[] = "MyKey";
j[_VAR1] = 10;
const char _VAR2[] = "MyKey";
j[_VAR2] = 10;
j[(const char)"MyKey"] = 10;
j[(char)"MyKey"] = 10;

There is a clear pattern. The signature of the template we want to instantiate (the path it takes when it works) is this or its const_reference counterpart:

template<typename T, std::size_t n>
reference operator[](const T (&key)[n])

It would seem that this template is being rejected because for a char* there won't be a second template parameter. The compiler then ignores this one and looks to all the single parameter templates, which are all equally bad (taking integers/enums) so it gives up.

The solution it would seem is to create another two template overrides in the general form:

template<typename T>
reference operator[](T* key)

To improve code reuse it would be better to put the actual code in this one and then call it from the char array one. There needs to be a complementary one for the const_reference case.

Add this in and it compiles under both gcc and VS2015. I've pushed this to my repo if you want to see it in action. I also added some extra unit tests to check all the combinations. AppVeyor and Travis continue to pass all tests.

[nlohmann]

Hi @twelsby, thanks for the further analysis and solution. I was missing the fact that char[] in fact worked...

[nlohmann]

@twelsby, would it be possible to open a separate PR for this issue?