Description
motivational examples from test/files/pos/depmet_implicit_oopsla_session_2.scala and neg/depmet_try_implicit.scala
def runSession[S, D](p: S, dp: D)(implicit s: Session[S]#HasDual[D]) =
s.run(p, dp)
def runSession[S, D](p: S, dp: D)(implicit s: Session[S]{type Dual=D}) =
s.run(p, dp)can we relax the ordering restrictions on dependencies so that we can write
def runSession[S](p: S, dp: s.Dual)(implicit s: Session[S]) =
s.run(p, dp)this is more than an encoding of the first two snippets as it hides the inference of D, so that you can specify S, but not D (unless you supply the implicit argument explicitly)
(Conceptually, it would be even nicer to be able to write the following, emphasizing the similarity between implicit arguments and type parameters)
def runSession[S][val s: Session[S]](p: S, dp: s.Dual) =
s.run(p, dp)It could work by re-arranging argument lists behind the scenes, possibly splitting up the
implicit argument list, so that the current left-to-right ordering requirement is upheld: types can only depend on arguments on their left.
This is related to the multiple type parameter lists generalisation:
def foo[A1, A2][B1, B2](p1 : (A1, B1)) : (A2, B2) = ...could be rewritten to:
def foo[A1, A2](p1 : (A1, w.B1))(implicit w: FooBs[A1, A2]) : (A2, w.B2) = ...