Unclear behaviour of positional / keyword parameters with same name

[msteindorfer]

The behaviour below was observed in the interpreter. Some on the following scenarios should probably be allowed (I didn't see a spec of keyword parameters), but the currently fail:

// Unclear behavour

data A = a(str name) | aUnknown(str name = "???");
a("hello").name // hello
aUnknown().name // NoSuchKey ; should work?
aUnknown(name = "hello").name // NoSuchKey ; should work?

data B(str name = "???") = b(str name) | bUnknown();
b("hello").name // hello
b(name = "hello").name // call failed
b("hello", name = "world").name // hello
bUnknown().name // NoSuchKey

Trivial use cases below seem to work, thus I assume it's causing issues when the same name at times can occur as positional or keyword parameter:

// Expected behaviour

data C(str name = "???") = c();
c().name // ???

data D(str name = "???") = d1() | d2();
d1().name // ???
d2().name // ???

data E = e(str name = "???");
e().name // ???

[DavyLandman]

I think, that the keyword parameters (which are fields that have a default value) are not allowed to overlap with other named fields.

I quite sure that the typechecker that @PaulKlint has worked on the last year would give you an error about this.

[mahills]

I'll need to check, we wrote that logic a couple of years ago. If it just doing a type compatibility check, a case like A could sneak through, but B should be a re-declaration of an existing field with the same name since it is declared at the type and constructor levels.

[jurgenvinju]

ok; this has been resolved by the type-checker. the interpreter does a random thing where the positional fields win. I'm calling this one "solved-by-type-checker"