Open kavedaa opened 1 month ago
The error should be in preventing such named tuple as defined by y
. I'm not sure if it's possible with current named tuple implementation.
The problem identified is manually constructing the type - it's on you to enforce the uniqueness - if you use the named tuple syntax, or any of the named tuple methods then there is a check
It's a bit like asInstanceOf
@bishabosha I think the questions should rather be:
I think the answer to 2) is clearly "yes". I don't have sufficiently technical knowledge to answer 1), but my assumption was that at y.a
the compiler has to at least look up which element corresponds to a
- if any at all - and that at that point it would be possible to detect that there was not only one but multiple elements having that name. I could be wrong of course.
There could probably be put in an ambiguity check on selection, here is the code taken from Typer
:
def tryNamedTupleSelection() =
val namedTupleElems = qual.tpe.widenDealias.namedTupleElementTypes
val nameIdx = namedTupleElems.indexWhere(_._1 == selName)
if nameIdx >= 0 && Feature.enabled(Feature.namedTuples) then // ? include extra `count == 1` check?
typed(
untpd.Apply(
untpd.Select(untpd.TypedSplice(qual), nme.apply),
untpd.Literal(Constant(nameIdx))),
pt)
else EmptyTree
otherwise the cost of peephole checking all types in case they might be some malformed named tuple might be too much
Compiler version
3.5.0-RC5 and others.
Minimized code
Expectation
Compilation error on
y.a
.