0008194: Optional Names for Formal Parameters

(0016518)
Jens Grabowski (manager)
05-09-2023 10:13

TTF discussion: Benefit is not obvious. Examples are needed.

(0016576)
Jens Grabowski (manager)
10-11-2023 10:19

TTF discussion: Matthias will provide examples and proposal.

(0016583)
Matthias Simon (developer)
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 (administrator)
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.

Issue History
Date Modified	Username	Field	Change
20-01-2023 13:26	Matthias Simon	New Issue
05-09-2023 10:13	Jens Grabowski	Note Added: 0016518
05-09-2023 10:13	Jens Grabowski	Assigned To	=> Matthias Simon
05-09-2023 10:13	Jens Grabowski	Status	new => assigned
10-11-2023 10:19	Jens Grabowski	Note Added: 0016576
21-12-2023 09:01	Matthias Simon	Note Added: 0016583
26-01-2024 16:32	Olivier Genoud	Note Added: 0016617

Notes
(0016518) Jens Grabowski (manager) 05-09-2023 10:13	TTF discussion: Benefit is not obvious. Examples are needed.

(0016576) Jens Grabowski (manager) 10-11-2023 10:19	TTF discussion: Matthias will provide examples and proposal.

(0016583) Matthias Simon (developer) 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 (administrator) 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.

Relationships

ETSI's Bug Tracker