Fix spelling

vendors to implement, in particular the assignment of `UNINITIALIZED` to the

iterator variable.

We therefore agreed to require the range-expression en to be

completely-qualified, if we iterator variable is defined outside the loop.

We therefore agreed to require the range-expression to be

completely-qualified if the iterator variable is defined outside the loop.

We also agreed to keep the current style of the specification. We don't plan to

specify the range-based loop as short-hand for the counter-loop, anymore.

specify the range-based loop as shorthand for the counter-loop anymore.

## Discussion: log-statement

The `log` statement won't be made a function, because the special parameter

handling rules of the statement had to be aligned with those of functions and

we won't be able to implement this change in this TTF.

The `log` statement won't be made a function because the special parameter

handling rules of the statement would have to be aligned with those of

functions, and we won't be able to implement this change in this TTF.

## Discussion: implicit omit for modified templates

    var template R modifies t1 t2 := { i := 2 } with { optional "implicit omit" }

```

Common understanding was: Implicit omit will change the modification from `{i:=2}` to `{i:=2,j:=omit}`

The common understanding is: Implicit omit will change the modification from `{i:=2}` to `{i:=2,j:=omit}`.

The content of t2 will be `{i:=2, j:=omit}`.

    log(t2) // What length-constraint will t2 have?

```

Following approaches have been discussed:

The following approaches have been discussed:

- **Overwrite length attribute**: Every template has a value and (at most one)

  length-constraint. But this statement is a implementation detail and not the

  length-constraint. But this statement is an implementation detail and not the

  behaviour one would expect.

- **Intersection**: Logically sound: `t1` restricts string to length(1..5),

- **Intersection**: Logically sound: `t1` restricts the string to length(1..5),

  when we restrict this set further, the resulting set is: `? length(3..5)`.

  A very similar behaviour is already specified by subtyping, too.

    p.receive(t); // does t match?

```

We assume that (in context of optional fields) `* length(1..4)` is semantically

equivalent to `? length(1..4) ifpresen`. Therefore template `t` should match.

We assume that (in the context of optional fields) `* length(1..4)` is semantically

equivalent to `? length(1..4) ifpresent`. Therefore, template `t` should match.

## Discussion: decmatch omit

A note in table 12 in clause 15 mentions a `decmatch` can match omitted fields.

A note in table 12 in clause 15 mentions that a `decmatch` can match omitted

fields.

```ttcn3

```

Resolution: Calling `decmatch` without actual data shall raise an error. In

this particular example a user shall wrap the `decmatch` in a ifpresent clause:

this particular example, a user shall wrap the `decmatch` in an ifpresent clause:

```ttcn3

    p.receive({f1 := decmatch integer:* }) // decoding error

## Discussion: modifying partially initialized templates

Question: Are the assignment-rules for modified templates the same as for 

the regular assignments?

Question: Are the assignment rules for modified templates the same as for

regular assignments?

Resolution: No.

Normal assignment overwrites the value on the left-hand side (first example).

Modifies expression does not (second example).

A normal assignment overwrites the value on the left-hand side (first example).

A modifies expression does not (second example).

```ttcn3 example="regular assignment -- templates"

- combined-matching-mechanisms (e.g. `'1*' length(5)`) are not included in the

  concatenation rules.

- concatenation rules for binary string templates with variable length are

  missing (e.v. `'1*' length(1..5)`).

  missing (e.g. `'1*' length(1..5)`).

- some results of concatenation are not representable in TTCN-3

  (e.g. `'1*1*'B length(6) & '1*1*'B length(6)`).

Discussion:

- Can we specify a mathematically correct concat operation?

  - Not possible without incompatible changes and considerate effort (i.e. no

  - Not possible without incompatible changes and considerable effort (i.e. no

    business value).

- Leaving the rules as they are is not an option, since we want to have

  language semantics implemented consistently across tools.

- Dropping length-restrictions when needed.

Resolution: Drop length-restrictions.

We keep compatibility at a pragmatic level for the price of loosing some

We keep compatibility at a pragmatic level at the price of losing some

precision in matching. A concrete proposal needs to be presented.

## Discussion: Language Simplifications

value (_value construct_, constants, variables, ...) and no concept for

template-types either.

Unfortunately we missed the time-frame to discuss these changes; since this

Unfortunately, we missed the time frame to discuss these changes because this

kind of simplification requires changes across many chapters in the standard

(e.g. Types and Values, Expressions, Templates, ...) and we have not come to a

evaluation for any compatibility issues.

(e.g. Types and Values, Expressions, Templates, ...), and we have not reached an

evaluation of any compatibility issues.

Therefore, we decided to keep the changes to the necessary minimum:

> if necessary changes cannot be done in the available time,

variables, module parameters, formal parameters, return values, expressions,

automatic type inference, type compatibility, ...)

This would be easy on BNF-level:

This would be easy at the BNF level:

```ebnf

VarDecl := "var" [TypeExpr] Name [":=" Expr].

TypeExpr := NestedTypeOrType | "template" NestedTypeOrType

```

Above would be incompatible to current specification:

The above would be incompatible with the current specification:

```

var a := 1; // "normal" variable with type `integer`

```

Introducing the concept of a template type is not possible within this

time-frame. Secondly, it was missed to be mentioned in the migration guide.

time frame. Second, it was omitted from the migration guide.

### Value Construct

The definition of variables, constant, module parameters, locals, component

The definition of variables, constants, module parameters, locals, component

variables, parameters, values and templates would greatly benefit from a common

concept.

They share rules like type compatibility, scoping, assignment, life-time, ...

They share rules like type compatibility, scoping, assignment, lifetime, ...

Biggest challenge was agreeing on how constants are to be specified.

The biggest challenge was agreeing on how constants are to be specified.

There have been a few proposals, but we could not reach a common understanding

for given time-frame.

within the given time frame.

We therefore agreed to focus on finishing the milestone and just simplify the

chapters where needed.

> NOTE: All types are known at compile time, i.e. are statically bound.

> [3.1 Terms and Definition]

Later restrictions in clause 10 has a much better wording (some version of

"constant expression"). However, restriction only covers constant expressions

A later restriction in clause 10 has much better wording (some version of

"constant expression"). However, the restriction only covers constant expressions

with constants and misses variables, module parameters and parameters; it seems

to imply global type definitions, but local types are unspecified:

> value, which actual value is null shall cause an error

> [11.1.h]

This restriction is too restrictive and out-of-place: As soon a variable is set

to `null` it would not be possible to change individual fields anymore. This error

should only be raised in a right-hand side context.

This restriction is too restrictive and out of place: As soon as a variable is

set to `null`, it would not be possible to change individual fields anymore.

This error should only be raised in a right-hand side context.

```ttcn3

```

Secondly, expansion rules in clause 7 are a better place to cover these rules

since variables are not the only place where `address` can be a type (e.g.

since variables are not the only place where `address` can be used as a type (e.g.

fields, elements, ...):

```ttcn3