here is a draft design for #13882: • https://docs.google.com/document/d/1mzZWnXiE6OkgMH_Dm7WeA3ck9veusQmr_c6GWPb_tsQ/edit feedback very welcome!

Love it. Halfway through I thought that a field marked as parametrizable could optionally have a method for producing the name for the address, in case the data is unusable as-is. But then were the configuration construct presented, and I think that is a workable approach to rid that issue wholesale. Great proposal!

Halfway through I thought that a field marked as parametrizable could optionally have a method for producing the name for the address, in case the data is unusable as-is. But then were the configuration construct presented, and I think that is a workable approach to rid that issue wholesale.

ah, yea: that was the conclusion that i came to… i started to go down a rabbit hole around serialization of parameterizable fields in addresses, but in the end you want the address to be pretty short anyway

Even better. Love this direction.

i think that the design is almost finished, with the exception of two open questions: 1. the address syntax, and how it interacts with generators 2. ensuring that configuration and #13767 will play nice thanks for the help so far! from an implementation perspective, i believe that all of Parameterization can land without implementing Configuration, so i’ll be starting that today. but before landing Parameterization (and before cutting

2.10.0rc0

), we need to nail down the syntax: more discussion welcome. current thread on the doc, and in slack