ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details

ID | Project | Category | View Status | Date Submitted | Last Update
0007708 | Part 01: TTCN-3 Core Language | Clarification | public | 13-09-2017 10:26 | 30-12-2017 14:35

Reporter | Tomas Urban |
Assigned To | Gyorgy Rethy |
Priority | normal | Severity | minor | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version | v4.9.1 (published 2017-05) |
Target Version |  | Fixed in Version | v4.10.1 (published 2018-05) |
Clause Reference(s) | 6.2.5, 6.3.2.4
Source (company - Author) | Elvior

Summary | 0007708: Using dot notation with @default union values

Description

The last version of the core language specification introduced unions with default alternative which were required for resolving the problem with enabling XSD type or element substition in existing test suites.
The current rules use special compatibility rules that make the default alternative implicitly available. This is fine for assignments and expressions where the target type can be determined from the other operand or operator or their combination.
With dot notation, the situation is more complicated. First of all, dot notation is available for the union itself. For fields that are defined within the default field (e.g. if it is a record) and not inside the union, this should be fine as the compiler should be able to distinguish to which type the field belongs. However, if the field occurs in both types (union and default records), the situation is somehow ambiguous as shown in the following example:
type union U {
@default record {
record {
integer field
} equalName
} opt1,
record equalName {
bitstring field
}
}
...
var U v_union := {...}
var integer v_int := v_union.equalName.field;
Does this code reference a field inside the default alternative and pass without a problem (provided the default value is select) or the field points to the second alternative of the union and cause a static type incompatibility error?
My opinion is that the latter is true because of operator precedence rules. Dot notation operations are processed from left to right, thus the first dot resolves to the reference to the second alternative of the union variable and only after that the second dot is resolved (which references a bitstring that is incopatible with the variable of the LHS).
Of course technically it is possible (but much more complicated) to compile it so that the dot notation takes into account the type required by the assignment. However, I struggle to interpret the existing rules on compatibility of union types so that they support that idea.
In any case, the specification should provide more examples on using dot notation with unions containing a default alternative (including the example above) and if necessary, additional rules for this situation.

Steps To Reproduce |
Additional Information |
Tags | No tags attached.

Relationships

related to | 0007726 | closed | Gyorgy Rethy | Part 09: Using XML with TTCN-3 | Naming rules for unions with default alternative (used in substitutions)

Attached Files | CR7708-v1.docx (181,915) 25-10-2017 15:06 http://oldforge.etsi.org/mantis/file_download.php?file_id=3700&type=bug CR7708-v2.docx (181,866) 25-10-2017 15:56 http://oldforge.etsi.org/mantis/file_download.php?file_id=3701&type=bug CR7708-v3.docx (162,361) 26-10-2017 13:32 http://oldforge.etsi.org/mantis/file_download.php?file_id=3714&type=bug

Issue History
Date Modified | Username | Field | Change
13-09-2017 10:26 | Tomas Urban | New Issue |
14-09-2017 10:39 | Jacob Wieland - Spirent | Note Added: 0014827 |
24-10-2017 11:24 | Jens Grabowski | Note Added: 0014840 |
24-10-2017 11:24 | Jens Grabowski | Assigned To | => Tomas Urban
24-10-2017 11:24 | Jens Grabowski | Status | new => assigned
24-10-2017 11:25 | Jens Grabowski | Note Added: 0014841 |
25-10-2017 15:06 | Tomas Urban | File Added: CR7708-v1.docx |
25-10-2017 15:06 | Tomas Urban | Note Added: 0014876 |
25-10-2017 15:06 | Tomas Urban | Assigned To | Tomas Urban => Jacob Wieland - Spirent
25-10-2017 15:06 | Tomas Urban | Status | assigned => confirmed
25-10-2017 15:56 | Tomas Urban | Relationship added | related to 0007726
25-10-2017 15:56 | Tomas Urban | File Added: CR7708-v2.docx |
26-10-2017 13:32 | Jacob Wieland - Spirent | File Added: CR7708-v3.docx |
26-10-2017 13:33 | Jacob Wieland - Spirent | Note Added: 0014890 |
26-10-2017 13:33 | Jacob Wieland - Spirent | Status | confirmed => resolved
26-10-2017 13:33 | Jacob Wieland - Spirent | Fixed in Version | => v4.9.1 (published 2017-05)
26-10-2017 13:33 | Jacob Wieland - Spirent | Resolution | open => fixed
26-10-2017 13:33 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Gyorgy Rethy
30-12-2017 14:35 | Gyorgy Rethy | Status | resolved => closed
30-12-2017 14:35 | Gyorgy Rethy | Fixed in Version | v4.9.1 (published 2017-05) => v4.10.1 (published 2018-05)
30-12-2017 14:35 | Gyorgy Rethy | Note Added: 0014949 |

Notes

(0014827)
Jacob Wieland - Spirent
14-09-2017 10:39

Interesting case.
I think we need a clarification that explicit dot-notation is preferred to implicit @default-unwrapping when there is a conflict like in the given example.
I.e. the implicit interpretation of a union value should only be considered if the explicit is statically unsound.
Another way to go would, of course, be to disallow such definitions in the first place, i.e. not only need the field names on the union level be unique, they also shall not clash with potential field names from the type of the @default alternative. To me, that would be an acceptable restriction.

(0014840)
Jens Grabowski
24-10-2017 11:24

STF decision: 1) Follow Jacob's second proposal (i.e., "Another ...). 2) New CR for XML part required (to be submitted by Tomas)

(0014841)
Jens Grabowski
24-10-2017 11:25

(To be implemented until end of 2017)

(0014876)
Tomas Urban
25-10-2017 15:06

Resolution uploaded. Please check.

(0014890)
Jacob Wieland - Spirent
26-10-2017 13:33

some small reformulation which has been approved by Tomas has been done and then it is resolved

(0014949)
Gyorgy Rethy
30-12-2017 14:35

Added to master copy V4.9.2