Skip to content

Optional Names for Formal Parameters

Mantis ID/URL: CR8194
Clauses: 5.4.1 -- Formal Parameters
Affiliation: Nokia - Matthias Simon

Summary

Allow names of formal parameters to be optional.

Description

There are situations where a formal parameter is mandatory, but its name does not provide any function or use. Unusable names cost time and energy, in some cases even introduce even bugs.

Use-Cases and Examples

Example 1: external function with user-defined types

external function dispatch(Timestamp, Event) return bool;

type record Event { /* ... */ }
type integer Timestamp;

Example 2: abstract method with single parameter

// EXAMPLE 2
type class @abstract Comparator {
    function equals(object) return boolean
}

Example 3: Unused, but mandatory parameter

// EXAMPLE 3
// EventHandler-type requires functions with two formal parameters
type function EventHandler(in integer eventType, in charstring message);

// someFunction must define the second formal parameter to be compatible although it doesn't use it.
//
// This unused parameter might be considered a code smell and produce a compilation error.
function someFunction(in integer eventType, in charstring /* unused */) {
    log(eventType)
}

control {
    var EventHandler h := someFunction;
    // ...
}

Proposal

Change BNF to something like this:

FormalParameter ::= ["in"|"inout"|"out"] NestedType ([ArrayDef] | Name [ArrayDef] [":=" Expr])

Discussion is needed how to handle named arguments in function calls.

Alternatives

Some languages1 use placeholders, such as _, to indicate that a parameter is not used. This could be a possible alternative, but it would introduce a new concept to TTCN-3.

Would this change make TTCN-3 easier or harder to learn, and why?

Like with any language feature, there is a risk of misuse. For example the following split function. It is not clear which parameter is the haystack and which is the needle:

external function split(charstring, charstring) return record of charstring;

However, this change would make TTCN-3 easier to learn and use. Relaxed syntax rules simplify code writing, while omitting names for unused parameters reduces the cognitive load required to understand code snippets.
These improvements make TTCN-3 more intuitive, particularly for developers familiar with similar features in widely-used programming languages such as C, C++, Go, Java, C#, Rust, TypeScript, ...

Adopting familiar paradigms from other languages lowers the barrier to entry for new developers, fostering quicker adoption and improved productivity.

  1. Java, C# and Rust ↩

Edited by Matthias Simon