Re-thinking: Layering of configuration

[matthiasbeyer]

We currently (as of 0.13.x) support layering of configuration objects to merge configuration values.

This should be supported in the future as well.

---

Re-Thinking the layering mechanism

We might re-think the idea of layering a bit here.
Right now (AFAICR) the layering is executed on loading of the configuration. In future, we might implement this as an operation that happens on accessing the values.
This way, we would always keep all values from the sources and only "merge" the values when accessing a certain element.

Example:

# 1.toml
foo = 1
bar = 2

# 2.toml
bar = 3

// pseudo code:
Build config object
Register "1.toml"
Register "2.toml"
Access config at "bar"
  - Mechanism finds out that "bar" is from "2.toml" and its value is 3

[szarykott]

As much as it would be great for debugging purposes, it might impair performance of the solution. Is this proposal motivated by some real life problems that is solves?

EDIT: I've read linked issue.

@dnaka91, would it be enough if sources of configuration were traced on the builder level, but not on Config level? Taking a look at the code, I am wondering if this is not possible right now, via Debug print of the builder.

[matthiasbeyer]

As much as it would be great for debugging purposes, it might impair performance of the solution. Is this proposal motivated by some real life problems that is solves?

No, I am just thinking from the ground up how this crate could look like in the future.

[martinvonz]

Another benefit of preserving the layering after load-time is that the client application can iterate over the layers and print the configs in each layer. That came up in jj-vcs/jj#917 (comment)