Godot: Parsing error when using 'not in'

[verbalshadow]

line 19 always gives me an error(19,19): ':' expected at the end of line

if component.type() not in database.keys():

This happens in everything I have tried not in with code wise. A helpful forum user pointed out another way to make it work http://godotengine.org/topics/14086 but I feel like this should be correct usage.
entitymanager.gd.txt

[Faustabov]

The reason why this is incorrect is that 'not' is just a nice substitution for !, the 'not' operator, throwing ! in the middle of that line makes no sense.

if (component.type() in database.keys()):

Is asking a question, the result is a boolean result (is component.type() in database.keys()?), if you want to know when the result is not found then you need to ask the question with the right syntax:

if !(component.type() in database.keys()): or
if not (component.type() in database.keys()):

There is no compound operator of !in or not in, because there doesn't need to be, the syntax for that query already exists, if this issue bothers you syntactically then simply change the question you are asking from: is it not there? to is it there? then reverse your if and else cases

[akien-mga]

The not in operator exists in Python but indeed not in GDScript. As to whether it should be implemented, I don't have any strong opinion. As @Faustabov pointed it out, using not thing in list already works fine, so the gain of supported not in directly would likely be minimal and add some complexity to the parser.

[verbalshadow]

I'm fine with it not being added. I just thought this was a bug. However, GDscript is pitched as being python like so It should be important to note in the docs where it differs. I simply expected it to be python-ish because I did not see anything to the contrary on this subject.

[vnen]

IMO GDScript don't have to be like Python 1:1. I do agree that the docs should state that GDScript is not that much Python-like.

not in seems very natural indeed, though. But then again it is another complexity in the parser to maintain.

[volzhs]

I agreed.

[razcore-art]

I don't think this one is necessary really, just make it clear in the docs, that GDScript is different in some aspects to Python :). That's just syntactic sugar that isn't really necessary here.

[verbalshadow]

I see no reason we can't remove feature proposal label and add a documentation label and move the bug to the new godot-docs issue tracker.

[PLyczkowski]

Issue is still open, so resurrecting. IMO not in is very clean and natural - if it's not a big hassle, +1 for it being added.

[vnen]

I would add is not too if we're going that route.

[akien-mga]

I would add is not too if we're going that route.

Maybe with isn't as syntactic sugar? :P

[PrinceMerluza]

Checking in just to track this. Would like those syntactic sugar added.

[Anutrix]

Any updates? Would make the scripts slightly more readable.

[IceCubeDev]

I like that this issue is 4 years old now 🗡️

[Calinou]

@IceCubeDev Please don't bump issues without contributing significant new information. Use the :+1: reaction button on the first post instead.

Also, keep in mind adding this kind of syntax sugar has a cost. Not only it complexifies the parser, but it also means you now have two ways to achieve the same thing. This will make style guides difficult to follow as they'll most likely require you to use one style or the other.

I would prefer if we kept it like it currently is. Just display an explicit error message when attempting to use not in or is not.

[ThakeeNathees]

what this will do is simply replace like this when parsing:
(expr) not in (expr) => not (expr) in (expr)
but would this be a proper fix and does gdscript need this syntax sugar?

diff --git a/modules/gdscript/gdscript_parser.cpp b/modules/gdscript/gdscript_parser.cpp
index a37fc579e7..982a612ec4 100644
--- a/modules/gdscript/gdscript_parser.cpp
+++ b/modules/gdscript/gdscript_parser.cpp
@@ -1380,7 +1380,20 @@ GDScriptParser::Node *GDScriptParser::_parse_expression(Node *p_parent, bool p_s
                        case GDScriptTokenizer::TK_PR_IS: op = OperatorNode::OP_IS; break;
                        case GDScriptTokenizer::TK_CF_IF: op = OperatorNode::OP_TERNARY_IF; break;
                        case GDScriptTokenizer::TK_CF_ELSE: op = OperatorNode::OP_TERNARY_ELSE; break;
-                       default: valid = false; break;
+                       default: {
+                               if (tokenizer->get_token() == GDScriptTokenizer::TK_OP_NOT && tokenizer->get_token(1) == GDScriptTokenizer::TK_OP_IN && expression.size() > 0) {
+                                       Expression e2;
+                                       e2.is_op = true;
+                                       e2.op = OperatorNode::OP_NOT;
+                                       expression.insert(expression.size() - 1, e2);
+                                       tokenizer->advance();
+                                       op = OperatorNode::OP_IN;
+                                       valid = true;
+                                       break;
+                               }
+                               valid = false;
+                               break;
+                       }
                }

                if (valid) {

[akien-mga]

Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.

The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.

If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!