Add autocompletion for OS.has_feature()'s parameter

[Mickeon]

Describe the project you are working on

A not-so typical Puzzle Bubble-like that has made general use of OS.has_feature("debug")

Describe the problem or limitation you are having in your project

In my code I make decent use out of Feature Tags. Although I only use the most common ones, a great chunk of them are available by default, for developers that want to fine-tune their project when exporting.

However, there's a bit of a... moving back 'n' forth between the list of all Feature Tags and the Script Editor.
It's quite easy to be a little forgetful, misspell a Feature Tag and having to check the list once more just to make sure it's among the default ones. It definitely doesn't help that the Strings vary in length and capitalisation (in 3.x).

It's a bit of an annoyance, seeing as, in the average project, constant Strings are passed as arguments for OS.has_feature()s anyhow.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Add parameter autocompletion to OS.has_feature(), displaying all of the non-custom Feature Tags.

It's very similar to Input.is_action_pressed() and derivates, whose action autocompletion also aim to solve the same issue.

I don't have much else to say. If it could be integrated with custom Feature Tags it'd be nice too, but it doesn't look possible in any way as of now.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

(mockup):

If this enhancement will not be used often, can it be worked around with a few lines of script?

Not really. Well, you could assign each common Tag to a constant in a script, and they'll technically be autocompleted. Bit of a silly workaround.

Is there a reason why this should be core and not an add-on in the asset library?

No add-on can implement this.

[KoBeWi]

OS.has_feature("debug")

You can actually use OS.is_debug_build() instead.

[Mickeon]

Oh, the things one doesn't think about...

[vnen]

This should be easy to add, but I don't think the list of features is available anywhere. So either it should be hardcoded into GDScript auto-completion or we need add a central list of possible features in the editor to harness for the completion list.

[Calinou]

There's also the question of whether we should add hardcoded string constants such as OS.FEATURE_WINDOWS instead of improving autocompletion.

Constants have a few upsides over string literals:

• Faster (if you don't use StringName conversion with &"windows" yourself).
• No risk of typos – you get compile-time errors instead of run-time errors.
• Autocompletion does not require bespoke code, so this will also work in C# and GDExtension.

Using strings should still be supported for custom feature tags, but all default feature tags would have an associated constant.

[Mickeon]

All of those are very compelling arguments (there's some performance overhead concern #4234 #4023 (reply in thread)).
It'd be nice if they were constants, although upon a second look, I do find it makes the method look bloated.

# Note: "OS." behind the constants may be excluded should they be available in the global scope)
OS.has_feature(OS.FEATURE_WINDOWS) 
OS.has_feature(OS.FEATURE_IOS)

compared to the concise, more readable and less repetitive:

OS.has_feature("windows")
OS.has_feature("ios")

I believe suggesting Strings would also allow custom Feature Tags to be more easily included in the autocompletion, if that ends up being desirable.

Autocompletion does not require bespoke code, so this will also work in C# and GDExtension.

This is a very compelling argument in favour of constants. I may not be a fan of the way the method would look, but it'd be inconsiderate to not take the other languages in account. I could be very wrong, but most methods I know that suggest constants really only make use of constants. OS.has_feature() accepts any string without restriction, without fail, technically. Not sure about mixing and matching constants and fully written Strings, either...