I don’t think you understood what I said. I’m saying that you could be getting all worked up about it when an empty string is perfectly okay data. You’re assuming empty strings are a problem, which they may not be, in this case. And you’re all worried that he’s not thinking about doing proper checks, but he specifically remarked on wanting to use custom getters and setters. If I’m wrong, then I think this case would be better served by lateinit than null, since that’ll thrown an exception as soon as it’s referenced if it hasn’t had a decent value assigned yet. You could set up the same situation yourself with a custom getter or delegated property, but why do that when something baked into the language works so well?
Also, you pretty much said all the same things again, which isn’t really going to help.
Beyond that, in a more direct response to what you said, I can see where you’re coming from, but I largely disagree. Takipi did a study of errors raised in PRODUCTION environments, and they still found NPEs to be the most prevalently thrown exceptions. Sure, there are more automatic and natural ways of checking for null, but people still forget to check them, causing problems even in released versions. Granted, Kotlin forces you to deal with null when it’s allowed, but that doesn’t mean that a well thought-out “Null Object” isn’t a better solution. Heck, as mentioned before, lateinit is a better solution than nullability most of the time.