id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
1815	Type variables cannot be (explicitly) unified even though the compiler can unify them	adabe588@…	somebody	"Even though a type unification is obvious the compiler does not
always accept a type specified by a function that's called.

In the Side note in the code of #1814 this issue is shown. In the
`eq` function a type variable `A` is defined and used for
`element`. It has to be of the same type as `Element`, otherwise
the call to `equalityFunction` will fail (and a compilation error
occurs if that's attempted). `A currentElement` is rejected by
the compiler since `next` returns `Element`. This causes the
internal type `Element` to potentially have to propagate to any
uses outside of the package where a polymorphic function exists
that uses `eq`.

Mainly I would like `A` to be valid here so that this propagation
does not occur.

Additionally, it seems more reasonable that naming it `Element`
would fail since that type variable is free and there is no
indication in the written code that the unification occurs, but
that is less important.
"	defect	new	high	Future	Frontend	trunk