4 ms·
I think it could be really useful for assertions. assert(someObj => someObj.data); The cannonical way to write that currently would likely be something like:
by slaymaker1907 3y ago
I think it could be really useful for assertions.
assert(someObj => someObj.data);
The cannonical way to write that currently would likely be something like:
if (someObj) assert(someObj.data);
- quietbritishjim 3y agoI think the more canonical way would be assert(!someObj || someObj.data); Which seems fine as it is.
- Someone 3y ago> Which seems fine as it is. I don’t know you, but I guess that’s because of familiarity from years of seeing this kind of thing. I think “=>” is clearer because it is what (AFAIK) people learn at school.
- mnk47 3y agoSure, we learned "p => q" in discrete math, but we also learned "assert(someObj && someObj.data)" in CS101 or CS102. I think you're right, it is clearer, but not worth sacrificing the near universal familiarity of boolean expressions. I'd accept a change like this in Python, but it feels out of place in C++.
- KerrAvon 3y agoPython _really_ doesn't need more obtuse syntax. It's bad enough as it is.
- slaymaker1907 3y agoOld comment, but that's not quite right. The equivalent for implication is "assert(!someObj || someObj.data)" which is much more confusing to read. It's saying if someObj exists, then it should also have data. Upon reflection, I think a better example would be something like "assert(someObj.type == SomeObjType::Float => !isnan(someObj.data))". Without the new operator, it would be "assert(someObj.type != SomeObjType::Float || !isnan(someObj.data))" which doesn't make the intent clear.
- the-smug-one 3y agoYou probably did learn De Morgan's laws too, to be fair.
- quietbritishjim 3y agoYou are possibly right. But I really think the "or" form is genuinely easier to understand, even more so if you have less education in formal logic. You might learn "x => y" in school (I didn't!) but if you did it was probably in the context of making implication (modus ponens). You are told p=>q, and then later you also find that p is true, so you can deduce that q is true. That's easy enough. But figuring out whether p=>q is true is tricker (intuitively). Say someObj is falsey - is "someObj => someObj.data" true? Well, it is, because an implication p=>q is always true if p is not true e.g. "if normal dice rolls a 7 then the weather is rainy" is true because a normal dice never rolls a 7. Is that intuitively obvious for everyone? I can't believe it. Is "!someObj || someObj.data" true if someObj is falsey? That is really easy in comparison - maybe not everyone will just see it at a glance, but you just check the two subexpressions one at a time, and immediately notice that "!someObj" is true. (What about if it's truethy? Also easy - the first subexpression is false, so you move on to the second one - it's only true if "someObj.data" is truethy.)
- cmovq 3y agoWhy not: assert(someObj && someObj.data);
- maleldil 3y agoBecause that would be false if someObj is falsy. someObj => someObj.data, or !someObj || someObj.data (which are equivalent) would evaluate as true if someObj is falsy.
- clnq 3y agoThe point of implication is to say whether, in case P is true, that Q is true as well. If P is false, then the implication is always true. So it’s !P || Q. Or P=>Q as the author proposes. If(bValidate => IsValid()) { /* runs if either validation was unnecessary or passed */ } And that would be equivalent to (!bValidate || IsValid()).