4 ms·

Yes, it is, but the domain req. can change, requiring to handling an nullable result

thu2111 7y ago
Isn't that the one big situation where null safety really shines? Something that used to be required is now optional, so, you need to visit all the use sites to figure out what a sensible behaviour is when the data isn't there. Without null safety that could be quite tricky, especially when combined with type inference. The value could be stored and used only later, for instance. The compiler flagging where those fields are used without a null check is convenient, it tells you exactly where to insert new code to handle the missing data.
- tommyage 7y ago
  Thank you, I shall be more precise when giving any comment. Honestly, I have not considered the advantages from null-safetyness (rated anything..) properly before posting. I just wanted to rant about kotlin, since i hear too many prayers about it and my gud (stomach) tells me different. I am not able to put it into words, yet. I really appreciate your hint. Anyway, you are absolutely right and I am glad @jach posted an link (above) regarding my intuition (@shoutout). When I learned programming (with Java, 3 yrs. ago) my mentor pointed out that i included too null-checks, even though i was familiar with the entire code base. Just after reading a post on this platform I realized his real intention: Sometimes (most often!) we needlessy check for null. Since then, forcing me to check anytime for null feels wrong and kotlin is forcing me to do so. Eventually I just wanted to mention downsizes which comes into my way when using kotlin daily.. Thankfully..!
  - thu2111 7y ago
    You're welcome!
alexbanks 7y ago
Exactly. The whole point of null safety is so that null becomes an explicit decision, rather than an implicit/accidental decision. If the requirements change, so should the code (aka you have to refactor the previously nullsafe code to now become nullable).

Isn't that the one big situation where null safety really shines? Something that used to be required is now optional, so, you need to visit all the use sites to figure out what a sensible behaviour is when the data isn't there. Without null safety that could be quite tricky, especially when combined with type inference. The value could be stored and used only later, for instance. The compiler flagging where those fields are used without a null check is convenient, it tells you exactly where to insert new code to handle the missing data.

tommyage 7y ago
Thank you, I shall be more precise when giving any comment. Honestly, I have not considered the advantages from null-safetyness (rated anything..) properly before posting. I just wanted to rant about kotlin, since i hear too many prayers about it and my gud (stomach) tells me different. I am not able to put it into words, yet. I really appreciate your hint. Anyway, you are absolutely right and I am glad @jach posted an link (above) regarding my intuition (@shoutout). When I learned programming (with Java, 3 yrs. ago) my mentor pointed out that i included too null-checks, even though i was familiar with the entire code base. Just after reading a post on this platform I realized his real intention: Sometimes (most often!) we needlessy check for null. Since then, forcing me to check anytime for null feels wrong and kotlin is forcing me to do so. Eventually I just wanted to mention downsizes which comes into my way when using kotlin daily.. Thankfully..!
- thu2111 7y ago
  You're welcome!

alexbanks 7y ago

Exactly. The whole point of null safety is so that null becomes an explicit decision, rather than an implicit/accidental decision. If the requirements change, so should the code (aka you have to refactor the previously nullsafe code to now become nullable).