question and suggestion about toml11

[ToruNiina]

Thank you for the suggestion!

It seems that your methods lack const specifier. As the compiler says, non-const methods cannot be called if the object or reference is marked const.

So adding const to the member function or removing const from toml::value will fix the code (I didn't check it yet).

basic_value operator[](size_t pos) const // this
{
	if (!is_array())
		throw std::exception("not an array, cannot access position: " + std::to_string(pos));
	return as_array().at(pos);
}

And yes, as you pointed out, those methods would be useful in some cases. I also considered to add them previously, but I didn't add it at that time because I personally didn't need them. My application code reads configs table by table, so in my case, each toml::find call corresponds to each read_xxx_config function that returns an object. Additionally, although it does not affect the overall runtime efficiency, I didn't want to check the existence of a value twice. That's the reason why I didn't add it. But it is just one case. If it is needed, I will re-consider to add them. If you have a PR, it's always welcome.

The difficulty is that the consistency between toml::value and STL containers. std::vector::operator[] effectively does not throw (when the index is out-of-bounds, it just causes undefined behavior) and std::map::operator[] hardly throws unless key-value pair construction throws or memory allocation failed. But toml::basic_value::operator[] often throws because there is no other way to handle invalid type.

Also, std::map::operator[] construct a new value if the key is not found. But std::vector::operator[] doesn't. Although I prefer these behaviors, considering these, I think there is no intuitive behavior for toml::value::operator[] because it can store either a table or an array.

So I think it is good to have toml::value::at() rather than toml::value::operator[]. at() always checks the bounds and throws if the specified index or key is not found. With at(), we can throw an exception if the conversion or element access failed.

[ToruNiina]

Recently I got independent but identical suggestion about operator[]. It convinces me that this feature is strongly desired. So I have implemented it.

Note that I've implemented it in STL-like manner. v.at(1) checks if v is an array and its length is larger than 1. Contrary, v[1] does not check anything and never throws. If you need type- and bound-checking, use v.at(n).