When i work with null-types and I tried to access...
# announcements
f
When i work with null-types and I tried to access their attributes, functions etc.. in the members with null-types I need add
!!
or
?.
in every call. It's annoying, could be added a feature: Operator that spreads through the members. Sample:
Copy code
bob?.department?.head?.name
bob!!.department!!.head!!.name
Something like this: [Edit]
Copy code
bob.department.head*?.name
bob.department.head*!!.name
@Alexey Belkov [JB] , You know if it is on the Road-MAP or if there is any request for this feature? Or would it not be viable? Edit: I'm new with Kotlin but I'm not understand Why this request is so unpopular. Someone to give Feedback
👎 16
âž– 3
a
Kotlin nullable types are here to help you with errors that have tortured devs for a long time (The Null pointer exception). Removing it, would defeat the purpose of introducing nullable types. They are there to help you and remind you that you might be operating with a null at that point So, if you see doing a bunch of double bangs, its not the language with problem, you need to recheck your code.
f
@andylamax, I don't want to delete null-types only a short-version for cases where there are too many members with null-types.
@andylamax,
if you see doing a bunch of double bangs, its not the language with problem, you need to recheck your code.
In cases that you use third-party libs of Java or Kotlin/JS (e.g. HTML Element) these usually happen and you can't control it. Sample with Kotlin/JS:
Copy code
document.getElementById("lista")?.getElementsByTagName("li")?.get(2)
n
@frank, I find that the frequent question marks serve as a guardrail for me (and I almost never use double bangs). I want my code to look cluttered if there's truly that much uncertainty. It tells me that I need to give a lot of thought to what I do if the expression evaluates to null, because it almost certainly will some day. For example, in your Kotlin/JS code, there are in fact three distinct things that could go unexpectedly: • There could be no element with the ID "lista". • There could be no
li
tags within that element, if it exists. • There could be fewer than 3 of those
li
tags. Given how many assumptions you're making here, what those question marks tell you is that you really need to carefully think through what it would mean for any one of these expressions to be null, so that it falls back gracefully to some reasonable behavior. If you reduced them to a single operator, you wouldn't be forced to consider exactly what could go wrong.
(And this doesn't just apply to you. You might have thoroughly thought through the causes and effects of every possible null pointer in a given expression, but the developer who comes later to read your code won't have.)
a
We have no plans to implement such a feature at this time, but you can vote and follow https://youtrack.jetbrains.com/issue/KT-23771 for updates on this.
f
@nschulzke Thx for Feedback, I understand this it can lead to bad practices if you do not control null expressions.
I find that the frequent question marks serve as a guardrail for me.
If you reduced them to a single operator, you wouldn't be forced to consider exactly what could go wrong
Single operator can make a good combination with inlay hint of Intellij and show warnings in each null expression.