Config validation and changing strings to support NULL values

Looking at the system.site example from 📌 Add validation constraints to system.site Needs work I do not think any of the values should be nullable. I think the labels should always be strings. A empty string a slogan, for example, is better than a NULL for me. The UUID property is interesting because it is assigned during the installer but I do not think we should be making it NULLABLE because a NULL is not a valid value ever.

Came up with a new idea on #3443432-23: Add validation constraints to system.site → ... we can add a new constraint NotBlankAfterInstall that allows empty strings during install but not after. I think this will reduce the need for nullable and means that we can leave values as strings and not have type flip-flopping.

I've opened 📌 Add NotBlankAfterInstall constraint and use it for system.date:timezone.default Active to explore the NotBlankAfterInstall idea.

Most things in system.site that are being made nullable in 📌 Add validation constraints to system.site Needs work , are not actually nullable from the standpoint of a running drupal installation, this especially rings true for name and UUID.

However, I'm not so sure about others. What is the semantic meaning of page.403 / page.404 being an empty string. It means this is not configured, right? I think it makes more sense in that case for it being NULL, because we can say it has to be null or it has to be a valid path.

If it is not nullable, we can not be as strict on the shape of the value?

page:
  403: ''
  404: ''

page:
  403: null
  404: null

I think this will reduce the need for nullable and means that we can leave values as strings and not have type flip-flopping.

Type flip-flopping is not great. and it doesn't make our code more strict.
All it does, is allows us to assume if the value is a string, it's a valid value, but I would not like to see a lot of places introduce is_string as checks to see if it's the right value.

I don't yet have a fully formed opinion on what the best way forward is.

I've opened #3461428: Add NotBlankAfterInstall constraint and use it for system.date:timezone.default to explore the NotBlankAfterInstall idea.

I think this is a very valueable new constraint.

@borisson_ yeah I think for things like page.403 / page.404 - null meaning not configured is okay. I'm especially +1 on this use of null if you can configure an empty value in the UI and the setting is not used a label. For me labels should not be nullable as they are highly likely to me passed to a string function and TranslatableMarkup won't work with NULLs.

For me the situations is something like this:

• Labels / translatables should always be strings in config. If an empty string does not make sense then it should have a not blank or not blank after site install (as necessary) - for example system.site:slogan should allow blanks but syste.site:name should not allow blanks after install.
• Config data that is optional (not labels) should consider allowing a NULL for an empty value, especially if an empty string makes no sense. This is the system.site:page.403/4 case.
• Config data that requires a non blank value after install should not allow a NULL - this is the system.site:uuid case.

It will be hard to keep this in mind while reviewing config schema issues, but since it's a simple set of rules that are easily documented we should proceed like this, I think #6 tackles my concerns.