Use of a Value Class as a type argument for a specialized parameter could avoid boxing.

[scabug]

~/code/scala ./build/pack/bin/scala -Xexperimental 
Welcome to Scala version 2.10.0-20120324-225627-a532ba0600 (Java HotSpot(TM) 64-Bit Server VM, Java 1.6.0_29).
Type in expressions to have them evaluated.
Type :help for more information.

scala> class Meter(val m: Double) extends AnyVal
defined class Meter

scala> val km = new Meter(1000d)
km: Meter = Meter@408f4000

scala> object A { ((m: Meter) => m.m)(km) }
defined module A

scala> :javap -v A
Compiled from "<console>"
public final class A$ extends java.lang.Object
  SourceFile: "<console>"
  Scala: length = 0x
   
  ...

public A$();
  Code:
   Stack=5, Locals=1, Args_size=1
   0:	aload_0
   1:	invokespecial	#16; //Method java/lang/Object."<init>":()V
   4:	aload_0
   5:	putstatic	#18; //Field MODULE$:LA$;
   8:	new	#20; //class A$$anonfun$1
   11:	dup
   12:	invokespecial	#21; //Method A$$anonfun$1."<init>":()V
   15:	new	#23; //class Meter
   18:	dup
   19:	getstatic	#28; //Field .MODULE$:L;
   22:	invokevirtual	#32; //Method .km:()D
   25:	invokespecial	#35; //Method Meter."<init>":(D)V
   28:	invokeinterface	#41,  2; //InterfaceMethod scala/Function1.apply:(Ljava/lang/Object;)Ljava/lang/Object;
   33:	pop
   34:	return
  LineNumberTable: 
   line 9: 0


}

From the SIP-15 comments:

retronym: Is this just a restriction of the reference implementation, or a more fundamental limitation?

odersky: I don't know for sure, but would hope it's just the current implementation. Somebody needs to sort out the interactions with specialization. I won't have the time to do it, though.

I've started poking around in https://github.com/scala/scala/blob/master/src/compiler/scala/tools/nsc/transform/SpecializeTypes.scala#L295, so far I've managed to trigger use of the specialized constructor (but only as far as to hit a CCE.

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-5611?orig=1
Reporter: @retronym
Affected Versions: 2.10.0
See #6824

[scabug]

@VladUreche said:
Specialization will go through a bit of a redesign after the 2.10 release, and I'll look into this once we have the new version.

[scabug]

Jamie Allen (shinolajla) said:
This also should support multi-field Value Classes.

[scabug]

Jamie Allen (shinolajla) said:
In order to support multi-field Value Class specialization, this #6824 would need to be implemented first.

[scabug]

@VladUreche said:
Supporting multi-field value classes is much more difficult --

• For a single field it's enough to rewire the methods correctly (to use the value type)
• For multiple fields you need to create new methods for the value class and make sure they are compatible to the other specialized versions - which is a solvable but very tough challenge. I'm pretty sure it is compatible with specialization but it might not work with miniboxing, I'll have to look more into it.

Either way, let's first have multi-field value classes and we'll see afterwards.

[scabug]

Simon Sotak (the21st) said:
Since the multi-field value classes ticket has been Closed, can we get an update on this?

[scabug]

@retronym said:
This bug in not on our roadmap. I believe it will take a fairly invasive change the architecture of the specialization and erasure phases of the compiler, and we don't have the resources to take that on for Scala 2.12.

[scabug]

@VladUreche said:
This will have to wait until we have support from the underlying JVM, as all compiler-only approaches have performance drawbacks. :(