On Fri, Sep 17, 2021 at 12:28 PM Michal Petrov <mpetrov@redhat.com> wrote:
Okay, that makes sense except for this bit:

> Especially strange would be if I had an expression like "${foo.bar?}baz" and the default value for the property gets put in;

For one this wouldn't work and I don't think we want it to work, the default value will be put in only if the attribute resolution is empty (or if it's the reserved string if we're going with that), so "${foo.bar?}baz" would resolve to "baz". We're not looking for a way to "inject" the default value, we want the attribute definition to use its default value because the user didn't provide anything (as far as the definition is concerned). As such the optional expression doesn't make sense in any kind of nested context.

Definitely understood. The use case seems pretty clear: as a user, I need to be able to explicitly specify the default value of a property in the event that another property cannot be expanded.

However, the proposed implementation *is* defined to use the existing string expression interpolation engine. The contract for the engine is clear: wherever there is an expression, that expression is lexicographically replaced with the exact replacement string. By stipulating a new modified contract based on the use case (specifically, that certain expressions must stand alone), you're introducing a new and arguably unexpected behavior to the existing contract, which brings complications in terms of usability (principle of least surprise for example) as well as implementation (an extra check based on the kind of expression found).

On the other hand, since the contract of the interpolation engine *is* already existent, if the expression engine is used for this purpose in an idiomatic manner (i.e. a special expression argument, which is directly supported already by the expression API), then the user can easily extrapolate that the default value expression is just another expression and can be used in the exact manner of any other expression, and as a result the user has slightly more flexibility than what was originally required (which is not necessarily a bad thing, as long as the implemented functionality can be concisely described in documentation).

- DML • he/him