I have a custom class with a few properties.

Generally int/PoolStringArray properties are exposed in the inspector just fine but strings fail to show up, even if the getter/setter work fine.

but this and another getter returns String like so:

String get_enter() {...}

for node.cpp

get_name returns StringName.

Very little documentation exists that explains the differences between String/StringName etc internally, although I have guesses.

Since they are bound in the same way, I figure something is silently gone amiss.

If you tag someone with the at symbol, like @Calinou then they get a notification.

StringName is intended to be used for constant strings. It's an optimization that makes use of string interning to avoid comparing strings at run-time (which is slower than comparing integers or other primitive values). In master, there's a SNAME() macro that can be used to create StringNames in C++. However, there is no such macro in 3.x (which does not use string interning as much as master in general).

For most use cases, you want to use String, not StringName. StringName only has first-class support in GDScript in master, not 3.x.

@Calinou

Thanks for the info. StringName then is the same idea as String in Java (the VM interns all Strings because they are immutable)

My issue however is although I bind these for export to GDScript as a property, they fail to show up in the Editor Inspector and of course they aren't saved in a scene. GDScripts sees the calls and invokes them and they are part of the auto generated documentation.

The Setter/Getter take and return String.

The binding fails but the engine is silent about it. (Q: are there debug flags for this?)

The strings here are constant for their case use and in this case StringName would be ideal.

I searched and used binding from other code inside the engine, using StringName stuff as a template.

If I may ask also, how the heck does one define string constants? A file + line number for an example would be sufficient.

@Calinou

BTW these are the method signatures. I worry the const keyword is causing problems String get_exit(); void set_exit(const String &name);

Ah interesting. In C++ I have static string globals

const std::string EXIT = L"__exit";

Without any idea how to or if I can export these as class constants, I had set up access for the as a property but left the setter field to "".

So it has a get_EXIT but I had no set_EXIT

This seems to have been the problem, perhaps because I have a field on the class of the same name but it is exported as 'exit' with set_exit and get_exit

OK. It seems like the name class with a pseudo 'constant' was the main issue.

thanks for the info folks