Language Change Specification for Signatures Required in Association Lists

LCS Number:	LCS-2016-I03
Version:	1 {06-Feb-2017}
Date:	06-Feb-2017
Status:	Voting
Author:	Patrick Lehmann
Email:	Main.PatrickLehmann
Source Doc:	Signatures Required in Association Lists
Summary:	Handle overloaded generic subprograms in generic association lists.

Voting Results: Cast your votes here

Yes:

1. Patrick Lehmann - 2017-02-06 - ver 1
2. Martin Zabel - 2017-02-07 - ver 1
3. Thomas Preusser - 2017-02-07 - ver 1
4. Jim Lewis - 2017-02-21 - ver 1
5. Rob Gaddi - 2017-03-16 - ver 1

No:

Abstain:

1. Brent Hayhoe - 2017-02-16 Version 1 - Abstain due to lack of personal time for review.
2. Martin Thompson - 2017-02-17 Version 2 - Abstain due to lack of personal time for review.
3. Peter Flake - 2017-03-16 - ver 1 implementation complexity does not justify benefit

Style Notes

Changes are shown in red font.
Deletions are crossed out.
Editing or reviewing notes in green font.

Reviewing Notes

Generic subprograms can be overloaded, but mapping subprograms to such a formal parameter is not possible, because a formal name must be
unique. This LCS introduces signatures at a formal generic subprogram to allow multiple mappings in a generic map aspect.

Details of Language Change

4.5.3 Signatures

A signature distinguishes between overloaded subprograms and overloaded enumeration literals based on their parameter and result type profiles.
A signature can be used in a subprogram instantiation declaration, generic map aspect, attribute name, entity designator, or alias declaration.

[...]

6.5.7.1 General

[...]

formal_designator ::=
    generic_name [ signature ]
  | port_name
  | parameter_name

[...]

6.5.7.2 Generic map aspects

[...]

In each case, for a formal generic constant, it is an error if a scalar formal is associated with more than one actual, and it is an error if a scalar subelement
of any composite formal is associated with more than one scalar subelement of an actual. Similarly, for a formal generic type, a formal generic subprogram, or a
formal generic package, it is an error if the formal is associated with more than one actual. Thus, it is an error if two formal generic subprograms have the same
designator and the same signature. It is also an error if a formal generic subprogram has a signature, which is not listed in an interface subprogram declaration
for that designator.

An actual associated with a formal generic constant in a generic map aspect shall be an expression or the reserved word open. An actual associated with a formal
generic type shall be a subtype indication. An actual associated with a formal generic subprogram shall be a name that denotes a subprogram whose profile conforms
to that of the formal, or the reserved word open. The actual, if a predefined attribute name that denotes a function, shall be one of the predefined attributes
'IMAGE, 'VALUE, 'POS, 'VAL, 'SUCC, 'PRED, 'LEFTOF, or 'RIGHTOF.

[...]

Annex C

formal_designator ::=
    generic_name [ signature ]
  | port_name
  | parameter_name

Comments

@TODO solicit input from vendors

-- Jim Lewis - 2017-03-02

PF: implementation complexity does not justify benefit

PL: what complexity? Signatures to distinguish subprograms are already implemented in the language.

The last revision didn't address this very need, that's why it's an ISAC issue. Other concepts like LCS 059 require this language bugfix.

I know there is a workaround which is more than ugly and adds a lot of complexity to the user code to work around a design fault from 2008.

So please elaborate what complexity do you mean?

-- Patrick Lehmann - 2017-03-09

This is completely unnecessary syntax. No signature is required to unambiguously associate a suprogram with the appropriate (named) formal using the standard subprogram overloading rules.

The LRM rule is too strict as written (stating that a formal name can only appear once) and can be relaxed to allow the associations without additional syntax. The formal name limitation should rather be that each (overloaded) formal can only be associated once after overload resolution.

I know this is already approved, but it is worth re-opening this issue since the syntax adds no value.

-- Karl Eisenhofer - 2017-03-24