[…] Why? […]Why? I’ll explain you why.
This line creates two symbols for every enumeration data type member.
TMyType = (typeA, typeB);
Here, you actually want to write
TMyType = MyTypes.TMyType;
Why someone should expect a "transitive" visibility of an identifier defined in a compilation unit not directly included in a use clause? […]Because this would significantly clean up uses-clauses:
Why someone should expect a "transitive" visibility of an identifier defined in a compilation unit not directly included in a use clause? AFAIK, identifier visibility is clearly defined and doesn't possess such a transitivity.
*snip*I'm not sure what are you talking about. The chapter is about type aliases, not identifier visibility.
Quoted from https://www.freepascal.org/docs-html/ref/refse19.html (https://www.freepascal.org/docs-html/ref/refse19.html) :
"This construction is often seen after some refactoring, when moving some declarations from unit A to unit B, to preserve backwards compatibility of the interface of unit A."
With enumeration type using $SCOPEENUMS off (default), this does not preserve backward compatibility.Again, what do you mean? What compatibility? Your original post was "Why I can't use the single enumeration identifiers although I have used a unit which defines a type alias to the original enumeration type (which is in a separate unit, a third one). The answer is simple and is given by Kays - you just didn't used the unit in which the particular identifier is defined.
@Kays Thank you.
When we make type alias of enumeration type, it looks like compiler turns on $SCOPEENUMS silently even though it does not.