implicit

I'm using implicit def to build a recursive HList type, to match several kind of higher kinded types of HList . I'm heavily inspired by this post . This code is working perfectly : sealed trait HList { type Plus[L <: HList] <: HList } class HNil extends HList { type Plus[L <: HList] = L def ::[T](v: T) = HCons(v, this) } case class Appender[L1 <: HList, L2 <: HList, R <: HList](fn: (L1, L2) => R) { def apply(l1: L1, l2: L2) = fn(l1, l2) } object HNil extends HNil object HList { def ++[L1 <: HList, L2 <: HList](l1: L1, l2: L2)(implicit f: Appender[L1, L2, L1#Plus[L2]]): L1#Plus[L2] = f(l1, l2)

I wonder why List(3,2,1).toIndexedSeq.sortBy(x=>x) doesn't work: scala> List(3,2,1).toIndexedSeq.sortBy(x=>x) // Wrong <console>:8: error: missing parameter type List(3,2,1).toIndexedSeq.sortBy(x=>x) ^ <console>:8: error: diverging implicit expansion for type scala.math.Ordering[B] starting with method Tuple9 in object Ordering List(3,2,1).toIndexedSeq.sortBy(x=>x) ^ scala> Vector(3,2,1).sortBy(x=>x) // OK res: scala.collection.immutable.Vector[Int] = Vector(1, 2, 3) scala> Vector(3,2,1).asInstanceOf[IndexedSeq[Int]].sortBy(x=>x) // OK res: IndexedSeq[Int] = Vector(1, 2, 3) scala> List(3,2,1)

Consider the default codec as offered in the io package. implicitly[io.Codec].name //res0: String = UTF-8 It's a "low priority" implicit so it's easy to override without ambiguity. implicit val betterCodec: io.Codec = io.Codec("US-ASCII") implicitly[io.Codec].name //res1: String = US-ASCII It's also easy to raise its priority level. import io.Codec.fallbackSystemCodec implicit val betterCodec: io.Codec = io.Codec("US-ASCII") implicitly[io.Codec].name //won't compile: ambiguous implicit values But can we go in the opposite direction? Can we create a low level implicit that disables ("ambiguates

It seems to me its very easy to implement an implicit operator versus a TypeConverter, so I'm assuming they aren't equivalent because of the prevalence of TypeConverters in the framework (see anything that extends FrameworkElement). But why? Wouldn't it have been much easier to create string->object and object->string implicit operators and take advantage of those in serialization (both XML and XAML)? Is it YAGNI? Single responsibility? Because you can't specify operator overloads in interfaces? Type converters are a lot more complex than they seem; a type-converter has access to a range of

Suppose I have the code: class A(implicit s:String = "foo"){println(s)} object X { implicit val s1 = "hello" } object Y { import X._ // do something with X implicit val s2 = "hi" val a = new A } I get the error: <console>:14: error: ambiguous implicit values: both value s2 in object Y of type => String and value s1 in object X of type => String match expected type String val a = new A Is there any way I can tell Scala to use the value s2 in Y ? (if I rename s2 to s1 , it works as expected but that is not what I want). Another solution is to not do import X._ , again something I'm trying to

Scala functions has following methods for chaining: fn1.andThen(fn2) fn1.compose(fn2) But how can be written this case: I have function cleanUp() which has to be called always as last step. And I have a bunch of other functions, like that: class Helper { private[this] val umsHelper = new UmsHelper() private[this] val user = umsHelper.createUser() def cleanUp = ... // delete user/ and other entities def prepareModel(model: TestModel) = { // create model on behalf of the user } def commitModel() = { // commit model on behalf of the user } } And some external code can use code something like this

The question is based on the discussion here . This is the setup: implicit def CToC2(obj: C1): C2 = { new C2() } class C1() { def f[U](f: (Int, Int) => U): U = f(1, 1) } class C2() { def f[U](f: ((Int, Int)) => U): U = f(2, 2) } I'd expect that trying to call the function with a signature that exists in C2 , scala would use the implicit conversion to satisfy the call: val c1 = new C1() val ff: ((Int, Int)) => Unit = t => println(t._1 + t._2) But this fails: scala> c1.f(ff) Error:(16, 7) type mismatch; found : ((Int, Int)) => Unit required: (Int, Int) => ? Interestingly if I drop the type

The following code generates a compile error in Xcode: template <typename T> struct Foo { Foo(T Value) { } }; int main() { Foo MyFoo(123); return 0; } error: missing template arguments before 'MyFoo' Changing Foo MyFoo(123); to Foo<int> MyFoo(123); fixes the issue, but shouldn't the compiler be able to figure out the appropriate datatype? Is this a compiler bug, or am I misunderstanding implicit template parameters? The constructor could in theory infer the type of the object it is constructing, but the statement: Foo MyFoo(123); Is allocating temporary space for MyFoo and must know the fully