Hi Attila, Attila Lendvai <att...@lendvai.name> writes:
[...] > also, seems like it didn't register in this discussion, so i press it > once again: if the default/unspecified value is a symbol (any symbol), > then those configuration fields, whose type is set to be of symbol, > will not error when they are left unspecified. (see the > FIELD-SANITIZER: it simply does a (IF (PRED VALUE) ...) check, which > doesn't fail because 'UNSET satisfies SYMBOL?). i should have added a > unit test for this... OK, I've reread this, and it is indeed a risk, that 'unset could leak in the case of a serializable configuration making use of a maybe-value field of type maybe-symbol. I've added the unit test suggested as 97cb43e732a38758c95b7caf3963507188d011cf (currently marked as 'expected to fail'). Luckily no current service uses that. I think the tension between serializable vs non-serializable unspecified values comes from the two kind of usages of define-configuration: one is to generate config files, in which unspecified means "nothing", and shouldn't touch disk, while in the case it's used as a more general data type (define-configuration/no-serialization), there is value in being able to lower that data type on the build/target so that things can be lazily computed where needed, without loss of information. We should add one more unit test to exercise this last usage in action (currently only jami-service-type makes use of that, but I have an upcoming Xvnc service that benefits from that as well). Thanks, Maxim
