← Back to context

Comment by weinzierl

1 day ago

I think INI-style config is one of the few good things that came out of the Microsoft/Windows ecosystem. Shame that it is so underspecified. We have TOML, of course, but I think for stupid config even that is too much.

The intersection of INI and TOML would be perfect.

TOML was created purely because INI has no format spec at all. So what you want is just TOML.

If you don't like certain things, just don't use them in your configs (i.e. tables)

What would you remove from TOML to make it perfect?

  • Tables.

    Not from TOML, just from my config language. TOML has other applications that require its complexity.

    I'd still keep simple INI style sections in my config lang, but they wouldn't have deeper meaning apart from grouping.

  • All scalar types other than strings (especially nonsense like datetimes). I'm already ingesting the configuration file as a string and parsing it into a language with actual types, e.g. Rust, and the act of parsing it into my defined configuration type will itself identify any problems with the config; having half-assed types like "int" in the config file format itself is not only useless, it's counterproductive because it requires people to ask questions like "okay, but what actually is the maximum range of integer values allowed to be contained in this type?". Just enforce UTF-8 encoded string values and let me take care of data validation.

    • The problem is that you end up with multiple dialects, just like INI.

      For example, I’ve seen booleans being represented with “enable”/“disable”, “yes”/“no”, “t”/“f”, “1”/“0”. Sometimes a mix in the same program.

      It’s nice that every TOML config requires “true”/“false” across any application.

      1 reply →

Isn't that called TOML?

  • An "intersection of INI and TOML" would presumably only have scalar values. TOML allows really complex lines like these:

      data = [ ["delta", "phi"], [3.14] ]
      temp_tagets = { cpu = 79.5, case = 72.0 }