if (This) {
if (is) {
if (much) {
if (better) {
println("I get paid by the brace")
}
}
}
} if (Actually
&& Actually.you
&& Actually.you.would
&& Actually.you.would.write
&& Actually.you.would.write.it
&& Actually.you.would.write.it.like) {
return this;
} what?.could?.possibly.go?.wrong = important_value()
if (!what)
what = new typeof(what); // default-construct representative instance
if (!what.could)
what.could = new typeof(what.could);
if (!what.could.possibly.go)
what.could.possibly.go = new typeof(what.could.posssibly.go)
// now assignment can take place and actually retain the stored value
// since we may have allocated what, we have to be sure
// we propagate it out of here.
what.could.possibly.go.wrong = important_value();
Why would you ever write an assignment, but not expect that it "sticks"? Assignments are pretty important.
What if someone doesn't notice the question marks and proceeds to read the rest of the code thinking that the assignment always takes effect? Is that still readable?
It should be clear enough that this operator isn't going to run 'new' on your behalf. For layers you want to leave missing, use "?.". For layers you want to construct, use "??=".
> Why would you ever write an assignment, but not expect that it "sticks"? Assignments are pretty important.
If you start with the assignment, then it's important and you want it to go somewhere.
If you start with the variable, then if that variable doesn't have a home you don't need to assign it anything.
So whether you want to skip it depends on the situation.
> What if someone doesn't notice the question marks and proceeds to read the rest of the code thinking that the assignment always takes effect? Is that still readable?
Do you have the same objection with the existing null-conditional operators? Looking at the operators is important and I don't think this makes the "I didn't notice that operator" problem worse in a significant way.
(Gets a lot better if you enable nullable references and upgrade the nullable reference warnings to errors.)
you didn't null check possibly.go.
Such a thing has been perpetrated in C. In C, you can repeat designated initializers. like
foo f = { .a = x(), .a = y() }
The implementaton is allowed to realize that since .a is being initialized again by y(), the earlier initialization is discarded. And it is permitted not to emit a call to x().
That's just like permitting x() not to be called in x() * 0 because we know the answer is zero.
Only certain operators in C short-circuit. And they do so with a strict left-to-right evaluation discipline: like 0 && b will not evaluate b, but b && 0 will evaluate b.
The initializer expressions are not sequenced, yet they can be short-circuited-out in left-to-right order.
Consistency? What's that ...
if (!same) {
return;
}
if (!number) {
return;
}
if (!of_braces) {
return;
}
println("but easier to read")