Logic shortcutting

Page: 1 2
May 3 2020, 7:53 am
Bumping again.
May 3 2020, 9:27 am
Instead of changing precedence of the logical NOT operator (because we KNOW that will break code somewhere, why not create a contains() function on lists? !list.contains(x) will work as expected. Did in ever get fixed Sayu?
Jul 26 2021, 9:59 am (Edited on Dec 20 2021, 2:33 pm)
I know I should probably have waited another year before bumping this thread just to make it every two years since 2014 but I was passing by.
Jul 27 2021, 6:27 pm
SS13 put this in our linter long while back because it sucks
Sep 13 2022, 10:27 am
Hiiii it's your old friend still hanging in there after all these years! You look good! Still young, like absolutely nothing has changed after all these years!
/client/verb/old_friend()
    var/list/L1 = list(1)
    var/list/L2 = list(2)
    var/list/L3 = list(L1,L2)
    world << "L1: list(1); L2: list(2); L3: list(L1,L2)"
    world << "1) 1 in L1: [1 in L1]"
    world << "2) 2 in L2: [2 in L2]"
    world << "3) 1 in L1 || 2 in L2: [1 in L1 || 2 in L2]"
    world << "4) L1 || 2: [L1 || 2]"
    world << "5) L1 || 2 in L2: [L1 || 2 in L2]"
    world << "6) L1 || 2 in L3: [L1 || 2 in L3]"
    world << "7) L2 in L3 in L1: [L2 in L3 in L1]"
    world << "8) 1 in L1 && 1: [1 in L1 && 1]"

L1: list(1); L2: list(2); L3: list(L1,L2)
1) 1 in L1: 1
2) 2 in L2: 1
3) 1 in L1 || 2 in L2: 0
4) L1 || 2: /list
5) L1 || 2 in L2: 0
6) L1 || 2 in L3: 1
7) L2 in L3 in L1: 1
8) 1 in L1 && 1: 0
Sep 13 2022, 4:09 pm
So, here's the problem: This was actually discussed in BYONDiscord recently, and it turns out that changing the precedence of the in operator isn't a good idea. Tom had thought it might be doable, although I was always worried it would break existing code. Having delved into this further, I think part of your request might be possible but dangerous, and a related issue is not possible at all.

First let's dive into the related problem of the ! operator. if(!a in b) doesn't work the same as if(!(a in b)), which is what people usually want instead, and they run into a lot of problems that way. It'd be great if they didn't have to worry about the parentheses. The problem comes in here:
if(thing in inventory + trade)

That's a legitimate construction, and it treats the if() as if(thing in (inventory + trade)) because the in operator has the lowest precedence. We definitely need + to be a higher precedence than in.

The ! operator has nearly the highest precedence, because it binds very tightly to things. Therefore we can say ! > + > in.

Now consider where the in operator were bound tighter than the ! oeprator, so in > !. This is an intransitive ordering because ! > + and we still need + > in. There's no way for the in operator to move above the ! operator because it would be intransitive.

The || and && operators aren't quite so bad, because their precedence is much lower, but I still worry about the impact this would have on code.
Sep 13 2022, 4:27 pm
I know there were other posts in this thread that suggested things like !in, but I would be happy with only the shortcutting logic operators being affected.

When you look at the examples, you can see just how out-of-order your logic has to be in order for the current order of operations to make sense. I for one will happily use logic shortcutting in assignment (x=dubious_var || default) and in general statement construction (doThing() || return), so I'm not saying "It should serve its original purpose and no other".

But a || b in c equating to (a in c) for all logically-true values of a is horrifying.
Sep 13 2022, 7:42 pm
Just as a side note, let me point out that `in` isn't even listed in the operator precedence list in the Ref
Sep 14 2022, 9:20 am
In response to Exxion
Exxion wrote:
Just as a side note, let me point out that `in` isn't even listed in the operator precedence list in the Ref

I'm addressing that in 515's ref.
Page: 1 2