Strange behaviour

[Paul Chisholm]

The following meaningless model compiles and runs successfully. I would expect the type checker to reject the declaration of t3. It seems to be just ignoring the 'set of' decoration.

type t1 = tuple(0..10,bool);

type t2 = tuple(11..20,0.0..1.0);

type t3 = set of t1 ++ t2;

var t3:x;

Result:

x = (0, false, 11, 0.0);

Changing to 

type t3 = set of t1;

does report the error that set element types other than 'int' not allowed.

[Jip Dekker]

Hi Paul,

That is indeed a bug. I've created an issue on the MiniZinc repository to track it: https://github.com/MiniZinc/libminizinc/issues/1009

It is likely that this is just that I missed a check to disallow set types when I implemented the concatenation of record/tuple types.

Cheers,

Jip

[Paul Chisholm]

Here is another one:

type singleton = tuple(int);

singleton: s = (1);

The type declaration passes, but the variable declaration raises an error "cannot determine coercion from type int to type tuple(int)"

Clearly the "(1)" is interpreted as a parenthesised expression rather than a tuple.

Looking at the grammar, the tuple type (production "<tuple-ti-expr-tail>") allows a single argument between the parentheses, but the tuple expression (production "<tuple-literal>") requires at least two arguments.

[Paul Chisholm]

Just remembered you can add the trailing comma so a singleton tuple is valid:

type singleton = tuple(int);

singleton: s = (1,);

output show(s);

And I misread the <tuple-literal> production, it does allow a single argument.