Introduce a has operator for bitsets.

[flysand7]

Bitsets have in operator, which checks whether a specific value is present in a bitset. The enumeration value is written first, and the bitset which you're making a subselection of is written second.

This has some issues for language servers and tooling that works with partially-complete AST's. Programmers write their code in a mostly-LTR fashion, so your AST might look something like this:

if .Pre
       ^ ctrl+space for completion, I want to auto-complete here!

The text editor has no way of knowing which bitset you're referring to (yet), so it can not display any meaningful hints. An alternative might be to type if in some_bitset, then move your cursor backwards and start typing the name of the bitset flag, which is kind of a lot of movements to type something so trivial.

This is where the idea comes in. We reverse the order of the bitset and the flags to make it easier for the tooling to have the necessary context for auto-completion without too much friction. Now the situation looks better:

if button_flags has .Pre
                        ^ now the tooling has context to suggest ".Pressing" as a candidate.

---

This has one potential downside of introducing a new keyword into the new language. It's not a verb or a noun, so very unlikely to interfere with the existing and new code. Definately not as inconvenient as package.

[flysand7]

The other problem that has surfaced is that the in syntax collides with for/in syntax for loops, meaning the following code is invalid syntax

for .Do_Parent not_in element.flags {
  element = element.parent
}

[flysand7]

The official answer to this so far is "No, because it feels weird".

Oh well. Keeping the discussion open though

[barnamumtyan]

I also wanted to create a request for introducing the has keyword, but with different argumentation.
I will just paste my case in here:
Is your feature request related to a problem? Please describe.
I like the way odin has this consistency of variables being on the left, and types being on the right, using : for definition, and = for assignment. It makes it very ergonomic to use.
But I have this problem with the in keyword used for maps and bit_sets, to me the order of [element, container]
e in A
e not_in A
this order to me seems wrong and doesn't align with other syntax with a container and an element, like array, map, they, both have the order [container, element]
a[x]
m[key]

It also makes these two very different loops very easy to confuse
for x in y {} // range loop
for (x in y) {} // condition-only for-loop (while-loop in some other languages)
Because other languages use parentheses with for loops, programmers become blind to it, and it is very hard to see while debugging whether the parentheses are there or not

Describe the solution you'd like
The solution would be to replace the in keyword for maps and bit_sets with has
Checking if an element is in a bit_set:
A has e
A not_has e
Checking if a key is in a map:
ok := m has key
It aligns the order with the map syntax [container, element]
elem, ok := m[key]

A for loop with a condition:
for x in y {} // range loop
for y has x {} // condition-only for-loop (while-loop in some other languages)
It is a lot clearer which one is which