Logo etsi

ETSI's Bug Tracker
Main | My View | View Issues | Change Log | Roadmap | Monitor project
  
Notice: information submitted on the ETSI issue Tracker may be incorporated in ETSI publication(s) and therefore subject to the ETSI IPR policy.

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007708Part 01: TTCN-3 Core LanguageClarificationpublic13-09-2017 10:2630-12-2017 14:35
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.9.1 (published 2017-05) 
Target VersionFixed in Versionv4.10.1 (published 2018-05) 
Summary0007708: Using dot notation with @default union values
DescriptionThe 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.
TagsNo tags attached.
Clause Reference(s)6.2.5, 6.3.2.4
Source (company - Author)Elvior
Attached Filesdocx file icon CR7708-v1.docx [^] (181,915 bytes) 25-10-2017 15:06
docx file icon CR7708-v2.docx [^] (181,866 bytes) 25-10-2017 15:56
docx file icon CR7708-v3.docx [^] (162,361 bytes) 26-10-2017 13:32

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

-  Notes
(0014827)
Jacob Wieland - Spirent (reporter)
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 (manager)
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 (manager)
24-10-2017 11:25

 (To be implemented until end of 2017)
(0014876)
Tomas Urban (developer)
25-10-2017 15:06

 Resolution uploaded. Please check.
(0014890)
Jacob Wieland - Spirent (reporter)
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 (reporter)
30-12-2017 14:35

 Added to master copy V4.9.2

- 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

MantisBT 1.2.14 [^]
Copyright © 2000 - 2024 MantisBT Team
Powered by Mantis Bugtracker