Les règles de visibilité
Les règles définissant la portée des déclarations et les règles définissant quels identifiants sont visibles à différents endroits du texte du programme sont décrites dans cette page. La formulation de ces règles utilise la notion de région déclarative.
Région déclarative
Une région déclarative est une partie du texte du programme. Une région déclarative unique est formée par le texte de chacun des éléments suivants :
- Une déclaration de sous-programme, une déclaration de paquet, une déclaration de tâche ou une déclaration générique, ainsi que le corps correspondant, le cas échéant. Si le corps est un stub de corps, la région déclarative inclut également la sous-unité correspondante. Si l'unité de programme comporte des sous-unités, elles sont également incluses.
- Une déclaration d'entrée ainsi que les instructions d'acceptation correspondantes.
- Une déclaration de type d'enregistrement, ainsi qu'une déclaration de type privé ou incomplet correspondante, le cas échéant, et ainsi qu'une clause de représentation d'enregistrement correspondante, le cas échéant.
- Une déclaration de renommage incluant une partie formelle, ou une déclaration de paramètre générique qui inclut soit une partie formelle, soit une partie discriminante.
- Une instruction de bloc ou une instruction de boucle.
Dans chacun des cas ci-dessus, la région déclarative est dite associée à la déclaration ou à l'instruction correspondante. Une déclaration est dite se produire immédiatement dans une région déclarative si cette région est la région la plus interne entourant la déclaration, sans compter la région déclarative (le cas échéant) associée à la déclaration elle-même.
Une déclaration se produisant immédiatement dans une région déclarative est dite locale à la région. Les déclarations dans les régions externes (englobantes) sont dites globales à une région déclarative interne (englobée). Une entité locale est une entité déclarée par une déclaration locale; une entité globale est une entité déclarée par une déclaration globale.
Certaines des formes de région déclarative ci-dessus incluent plusieurs parties disjointes (par exemple, d'autres éléments déclaratifs peuvent se trouver entre la déclaration d'un paquet et son corps). Chaque région déclarative est néanmoins considérée comme une portion (logiquement) continue du texte du programme. Par conséquent, si une règle définit une portion de texte comme le texte s'étendant d'un point spécifique d'une région déclarative jusqu'à la fin de cette région, alors cette portion est le sous-ensemble correspondant de la région déclarative (par exemple, elle n'inclut pas les éléments déclaratifs intermédiaires entre les deux parties d'un paquet).
Remarques : Le terme déclaration inclut les déclarations de base, les déclarations implicites et les déclarations faisant partie des déclarations de base, par exemple les spécifications discriminantes et de paramètres. Il résulte de la définition d'une région déclarative qu'une spécification discriminante apparaît immédiatement dans la région associée à la déclaration de type d'enregistrement englobante. De même, une spécification de paramètre apparaît immédiatement dans la région associée au corps du sous-programme englobant ou à l'instruction accept.
Le paquet STANDARD forme une région déclarative englobant toutes les unités de bibliothèque : la déclaration implicite de chaque unité de bibliothèque est supposée apparaître immédiatement dans ce paquet.
Les régions déclaratives peuvent être imbriquées dans d'autres régions déclaratives. Par exemple, les sous-programmes, les paquets, les unités de tâches, les unités génériques et les instructions de bloc peuvent être imbriqués les uns dans les autres et peuvent contenir des déclarations de type d'enregistrement, des instructions de boucle et des instructions accept.
Portée des déclarations
Pour chaque forme de déclaration, les règles de langage définissent une certaine partie du texte du programme appelée portée de la déclaration. La portée d'une déclaration est également appelée portée de toute entité déclarée par la déclaration. De plus, si la déclaration associe une notation à une entité déclarée, cette partie du texte est également appelée portée de cette notation (soit un identifiant, un caractère littéral, un symbole d'opérateur ou la notation d'une opération de base). Dans la portée d'une entité, et seulement là, il existe des endroits où il est légal d'utiliser la notation associée afin de faire référence à l'entité déclarée. Ces endroits sont définis par les règles de visibilité et de surcharge.
La portée d'une déclaration se produisant immédiatement dans une région déclarative s'étend du début de la déclaration à la fin de la région déclarative; cette partie de la portée d'une déclaration est appelée portée immédiate. De plus, pour chacune des déclarations répertoriées ci-dessous, la portée de la déclaration s'étend au-delà de la portée immédiate :
- Une déclaration apparaissant immédiatement dans la partie visible d'une déclaration de package.
- Une déclaration d'entrée.
- Une déclaration de composante.
- Une spécification discriminante.
- Une spécification de paramètre.
- Une déclaration de paramètre générique.
Dans chacun de ces cas, la déclaration donnée apparaît immédiatement dans une déclaration englobante, et la portée de la déclaration donnée s'étend jusqu'à la fin de la portée de la déclaration englobante.
En l'absence d'une déclaration de sous-programme, la spécification de sous-programme donnée dans le corps du sous-programme ou dans le stub de corps agit comme déclaration et la règle (e) s'applique également dans un tel cas.
Remarque : les règles de portée ci-dessus s'appliquent à toutes les formes de déclaration; en particulier, elles s'appliquent également aux déclarations implicites. La règle (a) s'applique à une déclaration package et donc pas à la spécification de package d'une déclaration générique. Pour les déclarations imbriquées, les règles (a) à (f) s'appliquent à chaque niveau. Par exemple, si une unité de tâche est déclarée dans la partie visible d'un package, la portée d'une entrée de l'unité de tâche s'étend jusqu'à la fin de la portée de l'unité de tâche, c'est-à-dire jusqu'à la fin de la portée du package englobant.
Visibilité
La signification de l'occurrence d'un identifiant à un endroit donné du texte est définie par les règles de visibilité et également, dans le cas de déclarations surchargées, par les règles de surcharge. Les identifiants considérés dans cette page incluent tout identifiant autre qu'un mot réservé, un désignateur d'attribut, un identifiant de pragma, l'identifiant d'un paramètre de pragma ou un identifiant donné comme paramètre de pragma. Les endroits considérés dans cette page sont ceux où un élément lexical (tel qu'un identifiant) apparaît. Les déclarations surchargées considérées dans cette page sont celles des sous-programmes, des littéraux d'énumération et des entrées simples.
Pour chaque identifiant et à chaque endroit du texte, les règles de visibilité déterminent un ensemble de déclarations (avec cet identifiant) définissant des significations possibles d'une occurrence de l'identifiant. Une déclaration est dite visible à un endroit donné du texte lorsque, selon les règles de visibilité, la déclaration définit une signification possible de cette occurrence. Deux cas se présentent.
- Les règles de visibilité déterminent au plus une signification possible. Dans un tel cas, les règles de visibilité suffisent à déterminer la déclaration définissant la signification de l'occurrence de l'identifiant, ou en l'absence d'une telle déclaration, à déterminer que l'occurrence n'est pas légale à ce point donné.
- Les règles de visibilité déterminent plusieurs significations possibles. Dans un tel cas, l'occurrence de l'identifiant est légale à ce point si et seulement si exactement une déclaration visible est acceptable pour les règles de surcharge dans le contexte donné.
Une déclaration n'est visible que dans une certaine partie de sa portée; cette partie commence à la fin de la déclaration sauf dans une spécification de package, auquel cas elle commence à l'endroit où le mot réservé est donné après l'identifiant de la spécification de package. (Cette règle s'applique, en particulier, aux déclarations implicites.)
La visibilité est soit par sélection, soit directe. Une déclaration est visible par sélection aux endroits définis comme suit :
- Pour une déclaration donnée dans la partie visible d'une déclaration de package : à la place du sélecteur après le point d'un nom développé dont le préfixe désigne le package.
- Pour une déclaration d'entrée d'un type de tâche donné : à la place du sélecteur après le point d'un composant sélectionné dont le préfixe est approprié pour le type de tâche.
- Pour une déclaration de composant d'une déclaration de type d'enregistrement donnée : à la place du sélecteur après le point d'un composant sélectionné dont le préfixe est approprié pour le type ; également à la place d'un nom simple de composant (avant le délimiteur composé =>) dans une association de composants nommés d'un agrégat du type.
- Pour une spécification discriminante d'une déclaration de type donnée : aux mêmes endroits que pour une déclaration de composante ; également à la place d'un nom simple discriminant (avant le délimiteur composé =>) dans une association discriminante nommée d'une contrainte discriminante pour le type.
- Pour une spécification de paramètre d'une spécification de sous-programme ou d'une déclaration d'entrée donnée : à la place du paramètre formel (avant le délimiteur composé =>) dans une association de paramètres nommés d'un appel de sous-programme ou d'entrée correspondant.
- Pour une déclaration de paramètre générique d'une unité générique donnée : à la place du paramètre formel générique (avant le délimiteur composé =>) dans une association générique nommée d'une instanciation générique correspondante.
Enfin, dans la région déclarative associée à une construction autre qu'une déclaration de type d'enregistrement, toute déclaration apparaissant immédiatement dans la région est visible par sélection à l'endroit du sélecteur après le point d'un nom développé dont le préfixe désigne la construction.
Lorsqu'elle n'est pas visible par sélection, une déclaration visible est dite directement visible. Une déclaration est directement visible dans une certaine partie de sa portée immédiate; cette partie s'étend jusqu'à la fin de la portée immédiate de la déclaration, mais exclut les endroits où la déclaration est cachée comme expliqué ci-dessous. De plus, une déclaration apparaissant immédiatement dans la partie visible d'un paquetage peut être rendue directement visible au moyen d'une clause use.
Une déclaration est dite cachée dans (une partie de) une région déclarative interne si la région interne contient un homographe de cette déclaration; la déclaration externe est alors cachée dans la portée immédiate de l'homographe interne. Chacune des deux déclarations est dite homographe de l'autre si les deux déclarations ont le même identifiant et si la surcharge est autorisée pour au plus l'une des deux. Si la surcharge est autorisée pour les deux déclarations, alors chacune des deux est homographe de l'autre si elles ont le même identifiant, le même symbole d'opérateur ou le même littéral de caractère, ainsi que le même profil de paramètre et de type de résultat.
Dans la spécification d'un sous-programme, chaque déclaration avec le même désignateur que le sous-programme est masquée; il en va de même dans une instanciation générique déclarant un sous-programme, et dans une déclaration d'entrée ou la partie formelle d'une instruction accept ; lorsqu'elle est masquée de cette manière, une déclaration n'est visible ni par sélection ni directement.
Deux déclarations apparaissant immédiatement dans la même région déclarative ne doivent pas être des homographes, à moins que l'une ou les deux conditions suivantes ne soient remplies : (a) exactement l'une d'elles est la déclaration implicite d'une opération prédéfinie ; (b) exactement l'une d'elles est la déclaration implicite d'un sous-programme dérivé. Dans de tels cas, une opération prédéfinie est toujours masquée par l'autre homographe ; un sous-programme dérivé masque une opération prédéfinie, mais est masqué par tout autre homographe. Lorsqu'elle est masquée de cette manière, une déclaration implicite est masquée dans toute la portée de l'autre déclaration (quelle que soit la déclaration qui apparaît en premier); la déclaration implicite n'est visible ni par sélection ni directement.
Chaque fois qu'une déclaration avec un certain identifiant est visible depuis un point donné, l'identifiant et l'entité déclarée (le cas échéant) sont également dits visibles depuis ce point. La visibilité directe et la visibilité par sélection sont également définies pour les littéraux de caractères et les symboles d'opérateur. Un opérateur est directement visible si et seulement si la déclaration d'opérateur correspondante est directement visible. Enfin, la notation associée à une opération de base est directement visible dans l'ensemble de la portée de cette opération.
Exemple :
Remarque sur la visibilité des unités de bibliothèque :
La visibilité des unités de bibliothèque est déterminée par les clauses with et par le fait que les unités de bibliothèque sont implicitement déclarées dans le paquet STANDARD.
Remarque sur les homographes :
Le même identifiant peut apparaître dans différentes déclarations et peut donc être associé à différentes entités, même si les portées de ces déclarations se chevauchent. Le chevauchement des portées de déclarations avec le même identifiant peut résulter de la surcharge de sous-programmes et de littéraux d'énumération. De tels chevauchements peuvent également se produire pour les entités déclarées dans les parties visibles du paquet et pour les entrées, les composants d'enregistrement et les paramètres, lorsqu'il existe un chevauchement des portées des déclarations de paquet, des déclarations de tâches, des déclarations de type d'enregistrement, des déclarations de sous-programme, des déclarations de renommage ou des déclarations génériques englobantes. Enfin, des portées se chevauchant peuvent résulter de l'imbrication.
Remarque sur la portée immédiate, le masquage et la visibilité :
Les règles définissant la portée immédiate, le masquage et la visibilité impliquent qu'une référence à un identifiant dans sa propre déclaration est illégale (sauf pour les paquets et les paquets génériques). L'identifiant cache les homographes extérieurs dans sa portée immédiate, c'est-à-dire dès le début de la déclaration; en revanche, l'identifiant n'est visible qu'après la fin de la déclaration. Pour cette raison, toutes les déclarations suivantes, à l'exception de la dernière, sont illégales :
La clause use
Une clause d'utilisation permet une visibilité directe des déclarations apparaissant dans les parties visibles des paquets nommés :
| clause_d_utilisation ::= use nom_du_paquet (, nom_du_paquet); |
Pour chaque clause use, il existe une certaine région de texte appelée la portée de la clause use. Cette région commence immédiatement après la clause use. Si une clause use est un élément déclaratif d'une région déclarative, la portée de la clause s'étend jusqu'à la fin de la région déclarative. Si une clause use apparaît dans une clause de contexte d'une unité de compilation, la portée de la clause use s'étend jusqu'à la fin de la région déclarative associée à l'unité de compilation.
Afin de définir quelles déclarations sont rendues directement visibles à un endroit donné par les clauses use, considérons l'ensemble des paquets nommés par toutes les clauses use dont les portées entourent cet endroit, en omettant de cet ensemble tous les paquets entourant cet endroit. Une déclaration pouvant être rendue directement visible par une clause use (une déclaration potentiellement visible) est toute déclaration qui apparaît immédiatement dans la partie visible d'un paquet de l'ensemble. Une déclaration potentiellement visible est en fait rendue directement visible sauf dans les deux cas suivants :
- Une déclaration potentiellement visible n'est pas rendue directement visible si l'endroit considéré se trouve dans la portée immédiate d'un homographe de la déclaration.
- Les déclarations potentiellement visibles ayant le même identifiant ne sont pas rendues directement visibles à moins que chacune d'elles ne soit soit une spécification littérale d'énumération, soit la déclaration d'un sous-programme (par une déclaration de sous-programme, une déclaration de renommage, une instanciation générique ou une déclaration implicite).
L'élaboration d'une clause use n'a aucun autre effet.
Remarque : les règles ci-dessus garantissent qu'une déclaration rendue directement visible par une clause use ne peut pas masquer une déclaration autrement directement visible. Les règles ci-dessus sont formulées en termes d'ensemble de paquets nommés par des clauses use.
Par conséquent, les lignes de texte suivantes ont toutes le même effet (en supposant un seul paquet (package) P) :
Exemple de noms conflictuels dans deux paquets :
- procedure R is
- package TRAFFIC is
- type COLOR is (RED, AMBER, GREEN);
- ...
- end TRAFFIC;
-
- package WATER_COLORS is
- type COLOR is (WHITE, RED, YELLOW, GREEN, BLUE, BROWN, BLACK);
- ...
- end WATER_COLORS;
-
- use TRAFFIC; -- La COLOR, le RED, l'AMBER et le GREEN sont directement visibles
- use WATER_COLORS; -- deux homographes de VERT sont directement visibles
- -- mais la COULEUR n'est plus directement visible
-
- subtype LIGHT is TRAFFIC.COLOR; -- Les sous-types sont utilisés pour résoudre
- subtype SHADE is WATER_COLORS.COLOR; -- le nom de type conflictuel COLOR
-
- SIGNAL : LIGHT;
- PAINT : SHADE;
-
- begin
- SIGNAL := GREEN; -- celui de TRAFFIC
- PAINT := GREEN; -- celui de WATER.COLORS
- end R;
Exemple d'identification de nom avec une clause d'utilisation :
- procedure R is
- package TRAFFIC is
- type COLOR is (RED, AMBER, GREEN);
- ...
- end TRAFFIC;
-
- package WATER_COLORS is
- type COLOR is (WHITE, RED, YELLOW, GREEN, BLUE, BROWN, BLACK);
- ...
- end WATER_COLORS;
-
- use TRAFFIC; -- La COLOR, le RED, l'AMBER et le GREEN sont directement visibles
- use WATER_COLORS; -- deux homographes de VERT sont directement visibles
- -- mais la COULEUR n'est plus directement visible
-
- subtype LIGHT is TRAFFIC.COLOR; -- Les sous-types sont utilisés pour résoudre
- subtype SHADE is WATER_COLORS.COLOR; -- le nom de type conflictuel COLOR
-
- SIGNAL : LIGHT;
- PAINT : SHADE;
-
- begin
- SIGNAL := GREEN; -- celui de TRAFFIC
- PAINT := GREEN; -- celui de WATER.COLORS
- end R;
Déclarations de changement de nom
Une déclaration de changement de nom déclare un autre nom pour une entité :
|
renommage_declaration ::= identifiant : marque_type renames nom_objet; | identifiant : exception renames nom_exception; | package identifiant renames nom_du_paquet; | specification_du_sous_programme renames sous_programme_ou_nom_entree; |
L'élaboration d'une déclaration de renommage évalue le nom qui suit le mot réservé renames et détermine ainsi l'entité désignée par ce nom (l'entité renommée). À tout moment où une déclaration de renommage est visible, l'identifiant ou le symbole d'opérateur de cette déclaration désigne l'entité renommée.
La première forme de déclaration de renommage est utilisée pour renommer des objets. L'entité renommée doit être un objet du type de base de la marque de type. Les propriétés de l'objet renommé ne sont pas affectées par la déclaration de renommage. En particulier, sa valeur et le fait qu'il s'agisse ou non d'une constante ne sont pas affectés; de même, les contraintes qui s'appliquent à un objet ne sont pas affectées par le renommage (toute contrainte impliquée par la marque de type de la déclaration de renommage est ignorée). La déclaration de renommage n'est légale que si exactement un objet a ce type et peut être désigné par le nom de l'objet.
Les restrictions suivantes s'appliquent au renommage d'une sous-composante dépendant des discriminants d'une variable. Le changement de nom n'est pas autorisé si le sous-type de la variable, tel que défini dans une déclaration d'objet, une déclaration de composant ou une indication de sous-type de composante correspondante, est un type non contraint; ou si la variable est un objet formel générique (de mode in out). De même, si la variable est un paramètre formel, le changement de nom n'est pas autorisé si la marque de type donnée dans la spécification du paramètre désigne un type non contraint dont les discriminants ont des expressions par défaut.
La deuxième forme de déclaration de changement de nom est utilisée pour le changement de nom des exceptions; la troisième forme, pour le changement de nom des paquets.
La dernière forme de déclaration de changement de nom est utilisée pour le changement de nom des sous-programmes et des entrées. Le sous-programme ou l'entrée renommé et la spécification de sous-programme donnée dans la déclaration de changement de nom doivent avoir le même profil de type de paramètre et de résultat. La déclaration de changement de nom n'est légale que si exactement un sous-programme ou une entrée visible satisfait aux exigences ci-dessus et peut être désigné par le nom de sous-programme ou d'entrée donné. De plus, les modes de paramètre doivent être identiques pour les paramètres formels qui se trouvent à la même position de paramètre.
Les sous-types des paramètres et du résultat (le cas échéant) d'un sous-programme ou d'une entrée renommés ne sont pas affectés par le renommage. Ces sous-types sont ceux donnés dans la déclaration de sous-programme d'origine, l'instanciation générique ou la déclaration d'entrée (et non ceux de la déclaration de renommage); même pour les appels qui utilisent le nouveau nom. D'autre part, une déclaration de renommage peut introduire des noms de paramètres et des expressions par défaut différant de ceux du sous-programme renommé ; les associations nommées d'appels portant le nouveau nom de sous-programme doivent utiliser le nouveau nom de paramètre; les appels portant l'ancien nom de sous-programme doivent utiliser les anciens noms de paramètres.
Une procédure ne peut être renommée qu'en tant que procédure. Une fonction ou un opérateur peut être renommé en tant que fonction ou opérateur ; pour le renommage en tant qu'opérateur, la spécification du sous-programme donnée dans la déclaration de renommage est soumise aux règles données pour les déclarations d'opérateur. Les littéraux d'énumération peuvent être renommés en tant que fonctions; de même, les attributs définis comme fonctions (tels que SUCC et PRED) peuvent être renommés en tant que fonctions. Une entrée ne peut être renommée qu'en tant que procédure; le nouveau nom ne peut apparaître que dans des contextes autorisant un nom de procédure. Une entrée d'une famille peut être renommée, mais une famille d'entrées ne peut pas être renommée dans son ensemble.
Exemples :
- declare
- L : PERSON renames LEFTMOST_PERSON;
- begin
- L.AGE := L.AGE + 1;
- end;
-
- FULL : exception renames TABLE_MANAGER.TABLE_FULL;
-
- package TM renames TABLE_MANAGER;
-
- function REAL_PLUS(LEFT, RIGHT : REAL ) return REAL renames "+";
- function INT_PLUS (LEFT, RIGHT : INTEGER ) return INTEGER renames "+";
-
- function ROUGE return COLOR renames RED;
- function ROT return COLOR renames RED;
- function ROSSO return COLOR renames ROUGE;
-
- function NEXT(X : COLOR) return COLOR renames COLOR'SUCC;
Exemple d'une déclaration de renommage avec de nouveaux noms de paramètres :
Exemple d'une déclaration de renommage avec une nouvelle expression par défaut :
Remarques : Le renommage peut être utilisé pour résoudre les conflits de noms et pour servir de raccourci. Le renommage avec un identifiant ou un symbole d'opérateur différent ne masque pas l'ancien nom; le nouveau nom et l'ancien nom n'ont pas besoin d'être visibles aux mêmes endroits. Les attributs POS et VAL ne peuvent pas être renommés car les spécifications correspondantes ne peuvent pas être écrites; il en va de même pour les opérateurs de multiplication prédéfinis avec un résultat universel fixe.
Les appels avec le nouveau nom d'une entrée renommée sont des instructions d'appel de procédure et ne sont pas autorisés aux endroits où la syntaxe requiert une instruction d'appel d'entrée dans les appels d'entrée conditionnels et temporisés ; de même, l'attribut COUNT n'est pas disponible pour le nouveau nom.
Un objet de tâche déclaré par une déclaration d'objet peut être renommé en tant qu'objet. Cependant, une tâche unique ne peut pas être renommée car le type de tâche correspondant est anonyme. Pour des raisons similaires, un objet d'un type de tableau anonyme ne peut pas être renommé. Il n'existe aucune forme syntaxique pour renommer une unité générique.
Un sous-type peut être utilisé pour obtenir l'effet de renommer un type (y compris un type de tâche) comme dans :
- subtype MODE is TEXT_IO. FILE_MODE;
Le paquet STANDARD
Les types prédéfinis (par exemple les types BOOLEAN, CHARACTER et INTEGER) sont les types étant déclarés dans un paquet prédéfini appelé STANDARD ; ce paquet inclut également les déclarations de leurs opérations prédéfinies. Outre les types numériques prédéfinis, la spécification du paquet STANDARD doit être la même pour toutes les implémentations du langage de programmation.
Le paquet STANDARD forme une région déclarative englobant chaque unité de bibliothèque et par conséquent le programme principal; la déclaration de chaque unité de bibliothèque est supposée se produire immédiatement dans ce paquet. Les déclarations implicites des unités de bibliothèque sont supposées être ordonnées de telle manière que la portée d'une unité de bibliothèque donnée inclut toute unité de compilation mentionnant l'unité de bibliothèque donnée dans une clause with. Cependant, les seules unités de bibliothèque étant visibles dans une unité de compilation donnée sont les suivantes : elles incluent les unités de bibliothèque nommées par toutes les clauses with s'appliquant à l'unité donnée, et de plus, si l'unité donnée est une unité secondaire d'une unité de bibliothèque, elles incluent cette unité de bibliothèque.
Remarques : Si toutes les instructions de bloc d'un programme sont nommées, le nom de chaque unité de programme peut toujours être écrit sous la forme d'un nom étendu commençant par STANDARD (à moins que ce paquetage ne soit lui-même caché).
Si un type est déclaré dans la partie visible d'un paquetage de bibliothèque, il résulte des règles de visibilité qu'une opération de base (comme une affectation) pour ce type est directement visible aux endroits où le type lui-même n'est pas visible (que ce soit par sélection ou directement). Cependant, cette opération ne peut être appliquée qu'aux opérandes étant visibles et la déclaration de ces opérandes nécessite la visibilité soit du type, soit de l'un de ses sous-types.
Contexte de la résolution de surcharge
La surcharge est définie pour les sous-programmes, les littéraux d'énumération, les opérateurs et les entrées uniques, ainsi que pour les opérations inhérentes à plusieurs opérations de base telles que l'affectation, les tests d'appartenance, les allocateurs, le littéral null, les agrégats et les littéraux de chaîne de caractères.
Pour les entités surchargées, la résolution de surcharge détermine la signification réelle d'une occurrence d'un identifiant, chaque fois que les règles de visibilité ont déterminé que plusieurs significations sont acceptables à l'endroit de cette occurrence; la résolution de surcharge détermine également la signification réelle d'une occurrence d'un opérateur ou d'une opération de base.
À un tel endroit, toutes les déclarations visibles sont prises en compte. L'occurrence n'est légale que s'il existe exactement une interprétation de chaque constituant du contexte complet le plus profond; un contexte complet est l'un des suivants :
- Une déclaration.
- Une instruction.
- Une clause de représentation.
Lors de l'examen des interprétations possibles d'un contexte complet, les seules règles prises en compte sont les règles de syntaxe, les règles de portée et de visibilité, et les règles de forme décrites ci-dessous :
- Toute règle exigeant qu'un nom ou une expression ait un certain type, ou qu'il ait le même type qu'un autre nom ou expression.
- Toute règle exigeant que le type d'un nom ou d'une expression soit un type d'une certaine classe; de même, toute règle exigeant qu'un certain type soit un type discret, entier, réel, universel, caractère, booléen ou non limité.
- Toute règle exigeant qu'un préfixe soit approprié pour un certain type.
- Toute règle spécifiant un certain type comme type de résultat d'une opération de base, et toute règle spécifiant que ce type est d'une certaine classe.
- Les règles exigeant que le type d'un agrégat ou d'une chaîne de caractères littérale soit déterminable uniquement à partir du contexte complet englobant. De même, les règles exigeant que le type du préfixe d'un attribut, le type de l'expression d'une instruction case ou le type de l'opérande d'une conversion de type soient déterminables indépendamment du contexte.
- Les règles pour la résolution des appels de sous-programmes surchargés; pour les conversions implicites d'expressions universelles; pour l'interprétation des intervalles discrètes avec des bornes ayant un type universel ; et pour l'interprétation d'un nom étendu dont le préfixe désigne un sous-programme ou une instruction accept.
Les noms de sous-programmes utilisés comme paramètres de pragma suivent une règle différente : le pragma peut s'appliquer à plusieurs sous-programmes surchargés, comme pour le pragma INLINE, pour le pragma SUPPRESS et pour le pragma INTERFACE.
De même, les noms simples donnés dans les clauses de contexte et dans les clauses d'adresse suivent des règles différentes.
Remarques : S'il n'y a qu'une seule interprétation possible, l'identifiant désigne l'entité correspondante. Cependant, cela ne signifie pas que l'occurrence est nécessairement légale car d'autres exigences existent n'étant pas prises en compte pour la résolution de surcharge; par exemple, le fait qu'une expression soit statique, les modes des paramètres, si un objet est constant, les règles de conformité, le forçage des occurrences pour une clause de représentation, l'ordre d'élaboration,...
De même, les sous-types ne sont pas pris en compte pour la résolution de surcharge (la violation d'une contrainte ne rend pas un programme illégal mais génère une exception lors de l'exécution du programme).
Une spécification de paramètre de boucle est une déclaration, et donc un contexte complet.
Les règles exigeant que certaines constructions aient le même profil de paramètre et de type de résultat relèvent de la catégorie (a); il en va de même pour les règles exigeant la conformité de deux constructions puisque la conformité exige que les noms correspondants aient la même signification par les règles de visibilité et de surcharge.