@oferron It's rare that a different order of implicit parameters will make a difference, but it does sometimes...
-
-
Replying to @propensive
@propensive I know implicit are evaluated in blocks, but the order shouldn't matter. Or at least be consistent.2 replies 0 retweets 0 likes -
Replying to @oferron
@propensive think about def foo[A, B](l:List[A], f:A=>B) Using this order, A can be inferred, but it won't be. Unless it's higher kinded2 replies 0 retweets 0 likes -
Replying to @oferron
@propensive where the order does matter cause it must resolve the constraint. I assume that's what happens in your example (I'm on the phone1 reply 0 retweets 0 likes -
Replying to @propensive
@oferron It means we can choose whether a parameter plays a part in an inferred constraint (i.e. by LUBbing) or not.1 reply 0 retweets 0 likes -
Replying to @propensive
@propensive but it plays hell with trying to get people to adopt.1 reply 0 retweets 0 likes -
Replying to @propensive
@propensive there is a problem in having common libraries in an industrial setting where only one of the experts can add features2 replies 0 retweets 1 like -
Replying to @oferron
@propensive and where the problem is not complexity (since libraries are complex), but arcana1 reply 0 retweets 0 likes
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.