This seems to eliminate the possibility of e.g. accented characters -- is that a concern? Do we support them now? And is there another method elsewhere in FC that handles this already?

maybe

Since what we really want to check here is that it is a valid python/expression identifier

Accented characters do not work for dynamic property names. I tried creating a dynamic property named 'Bä' and it failed.

obj.addProperty("App::PropertyFloat",'Bä')
Traceback (most recent call last):
File "", line 1, in
NameError: {'sclassname': 'class Base::NameError', 'sErrMsg': "Invalid property name 'Bä'", 'sfile': 'C:\bld\freecad_1734380974498\work\src\App\DynamicProperty.cpp', 'iline': 202, 'sfunction': 'class App::Property *__cdecl App::DynamicProperty::addDynamicProperty(class App::PropertyContainer &,const char *,const char *,const char *,const char *,short,bool,bool)', 'swhat': "Invalid property name 'Bä'", 'btranslatable': False, 'breported': False}

But note that Bä is a valid python identifier if you try to create a variable:

Bä = 42
Bä
42

Note also that the expression engine can handle this as an alias name. IMO, if it works with the expression engine, is a valid python identifier, doesn't conflict with a reserved unit name, could not be used as a cell address, and is not already in use, then it should be allowed. But it was never my intention with this or the previous PR to change alias validation.

Unfortunately, it appears that there's an assumption that identifiers will be represented by a subset of ASCII. The function performing validation is Base::Tools::getIdentifier() which uses comparisons to ASCII numeric values.

At any rate, the problem with the new structure is that we now have two copies of the exact same regex, something like ten lines apart. So setting aside the issue that we're being overly restrictive with our valid identifier checks (it turns out that's always been true), we have a new bit of code duplication. I think to fix the alias validation a bit more refactoring is required, to eliminate the doubled-up regex.

getIdentifier is not just validation though, it replaces characters that it doesn't consider valid, so maybe it's not appropiate for use here.

I think the re might not be needed in the cell address name validation. I will test and see if still works properly without it. If not, then it can be moved to a new function called by both of the others.

I removed the duplicate re from the cell address name validation function and it passed the c++ unit tests (and the other unit tests). The other re that remains will filter out unsupported characters for cell address names. The reason both were in there is a holdover from before the functions were separated.

Modifying permissiveness is beyond the scope of this PR. I just want to fix what is currently broken. If somebody wants to relax the restrictions, that can be done in a separate PR. But what is really needed is a bit of a bigger project -- a centralized validator that can be used to validate all user-generated names (aliases, constraints, and dynamic properties). This would make for a more consistent user experience. The same validator should work for all of these identifier types, but there might need to be additional restrictions handled locally in the spreadsheet or sketcher module, for example, "A1" is a good name for a constraint, but doesn't work well for a spreadsheet alias because it is also a valid cell address name. There might be similar names that work as aliases, but that create conflicts in sketcher, not sure on that. If a new validator is made, then it should also be accessible in python so workbenches and macros that create new aliases, constraints, or dynamic properties could also make use of it.