This page is no longer maintained — Please continue to the home page at

Re: Implicit class + inline class SID (Scala Improvement Document)

No replies
Joined: 2010-06-07,
User offline. Last seen 2 years 19 weeks ago.

On Aug 22, 2011, at 3:48 PM, Lukas Rytz wrote:

On Mon, Aug 22, 2011 at 15:34, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:
In the interest of keeping it simple to start, I was only going to allow classes with no parents to be inlined.  Kind of like a POD-type from C++.  Other classes would generate a compiler warning.   I would love to support the Rich* classes though.  I wonder if we could compromise with some kind of compromise...
for example RichInt could be marked @inline if all parents were also @inline, and then we can place restrictions on constructors to compile....  WDYT?

Sounds reasonable to me. An easy solution to check purity would be to allow only methods in @inline classes, no fields.

If you want to check for purity this article articles seems to give a nice approach to purity analysis. Haven't implemented it yet though so don't know how well it works:

On Mon, Aug 22, 2011 at 9:21 AM, Lukas Rytz <lukas [dot] rytz [at] epfl [dot] ch> wrote:
The transformation from "new Foo(2) plus 2" to "Foo.methods$.plus(1, 2)" preservessemantics only if the constructor of "Foo" does not have side-effects. Since "Foo"
might have superclass(es), as in 

  class RichInt(n: Int) extends Ordered[Int]
this is not trivial so to check; you'd need know that the super constructor call is side-effect-free, and you end up needing an effect system.. What's the plan? Just trust the user that inlining is fine when he writes "@inline class"?

On Mon, Aug 22, 2011 at 14:29, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:
Cross-posting to scala-language + scala-internals because I wasn't sure where else to push this.

You asked for it, and it's ready for public viewing!   Here is a modified proposal for implicit classes that includes the ability to inline classes.   The ulitmate goal of this proposal is for better 'implicit' performance within Scala.   Specifically for the extension method + typeclass/typetrait patterns embedded in Scala implicits.
Please take a look and offer constructive feedback!

Note:  This proposal does not include any syntax sugar fixes for defining typeclasses.  I have an alternative, much more controversial, SID that outlines an annotaiton-based approach to generating typeclass boilerlate.  I can send it to those who are interested, because it's designed to be acheived via annotations + a compiler plugin currently.
- Josh

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland