Do we really want StringTypeWithConstraints everywhere?

[enikao]

#1096 introduced StringTypeWithConstraints, and it's now effectively the type of any IETS3 string. This leads to several issues in our project:

• Everywhere we're testing for StringType we also need to test for StringTypeWithConstraints
• In Typesystem, we cannot test for StringType type equality anymore, need to test for subtype
• I haven't really measured it yet, but it feels like we have both a serious memory overhead (additional contents in temporarily created type nodes) and CPU overhead (e.g. from replacement rule checkStringConstraint)
• We have a field with a default value. If the default value is e.g. A, no other string is compatible with the field's type (inferred from its default value).

Is this worth the advantages? Maybe we could introduce a switch whether to support constrained types?

[alexanderpann]

I guess we should introduce an extension point to be able to go back to the old behavior. As a workaround, you should be able to create a new inference rule for StringLiteral in your language with overrides set to true and set the type back to the old string type.

[alexanderpann]

With the latest changes, StringType and StringTypeWithConstraints should be comparable and don't throw any errors. We need test case though to see if the change actual works.

[enikao]

One issue we have at the customer: Users should never see StringTypeWithConstraints as available type in autocomplete.

[alexanderpann]

I see. If you have your own root concept, you can disable it through the can be ancestor constraint.

[enikao]

I see. If you have your own root concept, you can disable it through the can be ancestor constraint.

... which we would need to do in several places. I still like the idea of an extension point, or a flag in PTF.