Today the dictionaryValue converts only from/to integer, float or boolean types. I am thinking about adding conversions from/to strings as well, so that dictionaries are a bit more flexible as a data exchange format.

Of course, string to int / double / bool would be done safely (using parseInt/ parseFloat... and checking that the number of bytes read is equal to the length of the string). 

Before doing this though, I'd like to know if you would be interested in integrating this feature in the library in the future (provided that the code works for you of course), as I would prefer to avoid forking. Also I am wondering if this is possible to implement it in a way that supports third party string implementations.

I have had a deeper look at it... Since dictionary already uses the std string implementation I guess it's not a problem to have a dependency on it :-).

So far it seems to be working pretty well, and it is quite useful to be able to cast from/to string, especially when dealing with text files dumped into a dictionary. I have implemented "unsafe" conversions in the end, since it is already done like this for double to int or int to double etc.

Since the cast is explicit, I guess it's not an issue.

By the way I have noticed a couple of weird return values in the Get function (it returns true when the conversion is not successful, and for booleans, it simply always return false).

I will upload a patch later if you are interested!

I'm definitely interested in seeing what you've done. 

Expanding on the existing dictionary type to make it more useful is always on my list of things to do, though I tend to prioritize core library features rather than add-on features.

Rather than making something specific for std::string, I really would prefer having the dictionary use the registered conversion routines so that it would work for all custom types. However, std::string is a good place to start.

But if I understand correctly there is no conversion routines for strings?

Not now, but it could be added. It just needs a few opConv methods to convert strings to primitives, and a few constructors to convert from primitives to strings.

It would be a bit inconsistent to allow a string to be converted to a number if it is stored in a dictionary, but not when it having the string value itself, don't you think?

Indeed, maybe that's the way to go then. I was just afraid of modifying the specification of strings in the language. I guess an explicit cast is preferred in this case (for literals to strings at least).

Yes, explicit conversions is what I have in mind.

For 2.33.0 I also plan to implement support for telling the compiler which conversion constructors can be used implicitly and which require explicit, so the same will apply for conversion from primitive to strings.

I've added the support for flagging conversion constructors/factories as 'explicit' now. Just add the keyword 'explicit' after the constructor's parameter list in the declaration to disallow its use in implicit conversions. 

This is available in revision 2541.

I have indeed seen this. Thanks!

For implicit constructor conversion, does it mean that the following code will compile?

any@ GetAny()
{
  int i=0;
  return i;
}

In theory yes, but you need to customize the 'any' add-on.