ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008194Part 01: TTCN-3 Core LanguageNew Featurepublic20-01-2023 13:2626-01-2024 16:32
ReporterMatthias Simon 
Assigned ToMatthias Simon 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusassignedResolutionopen 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)5.4.1 -- Formal Parameters
Source (company - Author)Nokia - Matthias Simon
Summary0008194: Optional Names for Formal Parameters
DescriptionThe current TTCN-3 specification requires formal parameters to have names, even when they are not used in the code, which can create confusion when using assignment notation and make the code harder to read.

To solve this problem, I propose that we allow developers to omit the names of formal parameters.

This change would reduce noise in the code, as unnecessary parameter names would no longer be required. It would be especially useful when specifying built-in functions and interfaces, as it would make the code more readable and easier to understand.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
20-01-2023 13:26Matthias SimonNew Issue
05-09-2023 10:13Jens GrabowskiNote Added: 0016518
05-09-2023 10:13Jens GrabowskiAssigned To => Matthias Simon
05-09-2023 10:13Jens GrabowskiStatusnew => assigned
10-11-2023 10:19Jens GrabowskiNote Added: 0016576
21-12-2023 09:01Matthias SimonNote Added: 0016583
26-01-2024 16:32Olivier GenoudNote Added: 0016617

Notes
(0016518)
Jens Grabowski   
05-09-2023 10:13   
TTF discussion: Benefit is not obvious. Examples are needed.
(0016576)
Jens Grabowski   
10-11-2023 10:19   
TTF discussion: Matthias will provide examples and proposal.
(0016583)
Matthias Simon   
21-12-2023 09:01   
It's helpful when parameters are not used, but mandatory. This happens for behaviour-types, abstract classes, traits and external functions:

    type function HandlerFunc(in Request) return Response;
    
    external function registerHandler(in HandlerFunc);

    // emptyHandler always returns an empty Response value
    function emptyHandler(in Request) return Response {
        return Response:{}
    }
(0016617)
Olivier Genoud   
26-01-2024 16:32   
According to the example it seems, that purpose of the CR is for use of a function as parameter or variable which is not part of the core language => The CR may enable a notation which only makes sense in the context of an extension package. On the other hand, the mentioned confusion can also be avoided by appropriate naming (e.g. "p_Dummy" or "p_NotUsed"). i.e. the issue can be solved by project-specific naming conventions rather than changing the core language.