I wouldn't use this and most people will forget that it exists. Most of the time you have do use the language and avoid hacks like that.
Don't you have alternatives in Dart?
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Follow the wormhole through a path of communities !webdev@programming.dev
I wouldn't use this and most people will forget that it exists. Most of the time you have do use the language and avoid hacks like that.
Don't you have alternatives in Dart?
I don't think so, the null aware operator doesn't rescue the nullable out of the parameter list.
overwriting [] seems like readability nightmare.
Won't something like this work more clearly?
extension NullCall<T> on T? {
R? let<R>(R Function(T) f) => this == null ? null : f(this as T);
}
void example() {
int? n;
n.let(math.sqrt);
}
This kind of immitates Kotlin let.
So you're using [] as an alternative function call syntax to (), usable with nullable parameters?
What's the alternative? let x = n is null ? null : math.sqrt(n);?
In principle, I like the idea. I wonder whether something with a question mark would make more sense, because I'm used to alternative null handling with question marks (C#, ??, ?.ToString(), etc). And I would want to see it in practice before coming to an early conclusion on whether to establish as a project principle or not.
math.sqrt?() may imply the function itself may be null. (? ) for math.sqrt(?n)? 🤔
I find [] problematic because it's an index accessor. So it may be ambiguous between prop or field indexed access and method optional param calls. Dunno how that is in Dart specifically.
Yeah pretty much as you said. I tried overriding ?[] to make it more clear but apparently ? operators can't be overriden.
I think I'll go for .callMaybe()
Don't overload things if the semantics don't match. You're not accessing something in a container; you're calling a function.