> A string value is not a great type to convey a user's email address or their country of origin. These values deserve much richer and dedicated types. I want a data type called EmailAddress which cannot be null.
Sure, I'm on board: I also want an e-mail address type. Just not in your shit language in which something can be of type String, yet be null reference.
Hmm, oh! C++ comes to mind. Of course, there is such a thing as null, but in:
void fun(string x) // std::string
{
}
x cannot be null. The reference semantics (like a copy of a string sharing the data with the original) is an implementation detail/optimization encapsulated inside what appears to be a value type.
The tools are there in C++ to create ideal types for your problem domain which just look like value types that have no null domain value (or any other value you don't want), and standard strings are like this.
Pointers to std::string are almost never required, though. A pointer to std::string is not something you have to use to write a string handling C++ program or module; and such a pointer p is itself not a string, *p is (if p is non-null and valid).
About the only time you would need a pointer to std::string when calling some C API that takes a callback function with a void * context, and you'd like that context to be a std::string. Then you might take the address of string object to pass to that API. (That pointer would likely never be null, but could go bad due to lifetime mismanagement.)
Most other uses of such a thing would be unidiomatic. Whereas, in some languages, string references that can be null are foisted on programmers as the standard, idiomatic string representation. That's a big difference.
But in Kotlin non-nullable types are the default. In C++ references are non-nullable. Both include nullable types too.
In that specific example, String can't be null in Kotlin and neither can string in C++, although you can make them nullable by using e.g. a pointer or an optional type.
Having everything be nullable like in Java is unarguably 100% a mistake.
Sure, I'm on board: I also want an e-mail address type. Just not in your shit language in which something can be of type String, yet be null reference.