I am not sure if you really need it because in the toml file you can simply write:
[MyType]
"α" = 1.0
"Ω" = 1.0
It’s up to you, but I don’t think the Symbol syntax is part of YAML standard specification I think it is a Julia specific thing in YAML.jl, thus you may have compatibility issues when you pass this to other people using other languages (e.g Python does not have the concept of Symbol or equivalent).
if you want to use TOML, you just need to overload Configurations.convert_to_option, it’s just one line, not sure why you don’t want to do it.
You will need the dictionary to use String as your key, but YAML parser by default returns Dict{Any, Any}, I think the error message has explained what’s happening
ERROR: LoadError: MethodError: no method matching from_dict(::Type{OPTION}, ::Dict{Any, Any})
Closest candidates are:
from_dict(::Type{T}, ::AbstractDict{String, V} where V; kw...) where T at C:\Users\pollaccoj\.julia\packages\Configurations\kq1sK\src\parse.jl:27```
so you want to write
YAML.load_file("test.yml"; dicttype=Dict{String, Any})
It’s needed when a REST API’s JSON schema is not defined by who writes the Julia struct, especially given that there are many other languages that do not support/encourage UTF8, but the Julia function we are going to call has UTF8 keywords which are quite common in Julia ecosystem.
I had a concrete use case when I wrap up JSON schema in IBM Quantum, but due to syntax conflict, this feature is removed since v0.12.0. The best way currently is to do the name convention manually.
The latest version of this package is currently v0.16, so please always use the documentation as reference instead of this discourse announcement.
for the comment in your other post
My recommendation is that Configuration.jl should be part of the TOML package.
no, it won’t be, this package is not specific to TOML, it supports TOML by default just because Julia has a TOML parser shipped with it.
1 Like
I realize the documentation was lack of examples of type conversions etc. so I just cut new patch release to update the documentations, this includes
Please remember to give a star if you find it’s helpful so that the future new releases will appear in your github feeding 
9 Likes
@Roger-luo I would like to give 10 
but can only give one
1 Like
@Roger-luo I am wandering if we should not invent TOMLJ (TOML for JULIA). This is useful as a format to input parameters/options into JULIA specific models 
You mean “if we should invent TOMLJ”? I guess we can, as long as we make syntax highlights happy in the IDEs etc, and as long as you implement a set of default string syntax for Julia types, I think you can just get it out of the box, but if you are fine with Julia specific things, you can also just use YAML which supports more syntax by its standard.
The only thing to be careful of is when you want other language users to be able to use your config file, be careful with the Julia-specific parts, since things like :symbol might be valid syntax in other languages or it could mean different things in another programming language.
I didn’t support this type of thing in the default conversion rules because the string syntax has some ambiguity based on context, e.g one my want ":symbol" to be converted to a Symbol when the type is Union{Symbol, String}, or sometimes one just want the string to be converted to a Symbol when the type is just Symbol.
So doing Julia-specific things is definitely possible and simple to do with Configurations by adding some extra type conversion rules from String, but we will need a separate package for that to enforce Julia specific things.