That's not what "Making illegal states unrepresentable" means.
Let's say you're trying to parse a user object. Let's further say users always have to have a last name - a user without last name would be illegal state.
Now if you're parsing some data for a user that really doesn't have a last name for some reason, there's two approaches to this problem - either you return a User with a null last name (which is essentially giving incorrect information to the caller). Or you make it impossible to set User.lastName to null (for example by making it an Optional) and fail with an error about what went wrong.
Of course you wouldn't NEED to restrict User.lastName to never be null - but if you always fail with an error in that case anyways, why not? That way any consumer of the User object knows that the lastName will always be there and valid.
But clearly, requiring a last name is wrong. If legitimate users can lack a last name, the system needs to work without last names: probably there should be a flexible "person's name" class that encapsulates first names, last names, titles etc. instead of attaching a raw last name to users.
The various parts of a person's name should be encapsulated in a specific class, and one of these objects, rather than a loose last name and other concrete fields, should be a mandatory attribute of a user object.
There should be only one place for name-handling logic, and since other people types besides users could appear in the domain model (commercial customer, social network "friend", relative, etc.) the user class isn't that place.
Let's say you're trying to parse a user object. Let's further say users always have to have a last name - a user without last name would be illegal state.
Now if you're parsing some data for a user that really doesn't have a last name for some reason, there's two approaches to this problem - either you return a User with a null last name (which is essentially giving incorrect information to the caller). Or you make it impossible to set User.lastName to null (for example by making it an Optional) and fail with an error about what went wrong.
Of course you wouldn't NEED to restrict User.lastName to never be null - but if you always fail with an error in that case anyways, why not? That way any consumer of the User object knows that the lastName will always be there and valid.