title: How about "this" as a type?
body: <p>I will simplify the problem that got me to this point, but I was thinking about this block of code :</p>
  <pre><code>abstract class A {
      fun myCustomApply(block: A.() -&gt; Unit): A {
          this.block()  // block() would have the same effect
          // Do something else here
          return this
      }
  }
  
  class B : A() {
      fun anotherFunction() {
          // Do something
      }
  }
  </code></pre>
  <p>This code looks (and is) ok. But consider the following snippet :</p>
  <pre><code>fun doSomethingVeryUseful(): B /* Won't work */ {
      val b = B()
      return b.myCustomApply {
          anotherFunction()  // Nope
      }
  }
  </code></pre>
  <p>Here, the compiler will complain, for two reasons, that may not seem obvious at first glance. First of all, <code>myCustomApply</code>'s <code>block</code> parameter was declared with type <code>A.() -&gt; Unit</code>, so we can't call <code>anotherFunction()</code> within its scope, because it was declared in class B.
  Then, it appears that <code>doSomethingVeryUseful</code>'s return type was declared as B, but <code>myCustomApply</code> returns A, so we have to use an <code>as A</code> cast.</p>
  <p>Both errors are logical, because the compiler can't guess by itself &quot;Oh yeah, the return type is A but it always returns <code>this</code>, so it is perfectly fine to do that !&quot;, but these are kinda painful to handle properly because I personnally can't think of a proper workaround.</p>
  <p>Of course, you could do something like this :</p>
  <pre><code>abstract class A
  
  class B : A() {
      fun anotherFunction() {
          // Do something
      }
  }
  
  fun &lt;T : A&gt; T.myCustomApply(block: T.() -&gt; Unit): T {
      this.block()
      // Do something else
      return this
  }
  </code></pre>
  <p>But I personnally think this is not a good idea, because it confuses the code (where does the myCustomApply come from ? Why isn't it in class A ?), and is a bit complicated for such a simple problem. You're free to think this is a good solution, but I don't really agree.</p>
  <p>My idea was to do something like this (don't try this in your IDE, it will just complain that you're the worst developper ever and that you doesn't even deserve to exist because it isn't actual syntax) :</p>
  <pre><code>abstract class A {
      fun myCustomApply(block: this.() -&gt; Unit): this {
          block()
          // Do something else
          return this
      }
  }
  
  class B : A() {
      fun anotherFunction() {
          // Do something
      }
  }
  
  fun doSomethingVeryUseful(): B {
      val b = B()
      return b.myCustomApply {
          anotherFunction()  // YEAH
      }
  }
  
  </code></pre>
  <p>Note that <code>this</code> is used in two places : as a receiver type and as a return type.
  As <code>this</code> already is a keyword, it wouldn't break any existing code, so backward compatibility is assured.</p>
  <p><code>this</code> as a type would have a single accepted value, that is, <code>this</code>. Why use <code>this</code> as a type ? This will garantee to the compiler that the value is effectively of the type of the receiver, that is <code>b.myCustomApply</code> now accepts a lambda of type <code>B.() -&gt; Unit</code>, and has a return type of type B, since <code>b</code> itself is of type B.</p>
  <p>Another (purely aesthetic) advantage would be that it is now clear that the same object (that is, the receiver) will be passed to the lambda, and then returned to the caller of the method.</p>
  <p>This would translate to something like this :</p>
  <pre><code>
  abstract class A&lt;_this : A&lt;_this&gt;&gt; {
      private fun _this(): _this =
           @Suppress(&quot;UNCHECKED_CAST&quot;) (this as _this)        
      
      fun myCustomApply(block: _this.() -&gt; Unit): _this {
          _this().block()
          // You got the idea
          return _this()
      }
  }
  
  class B : A&lt;B&gt;() {
      fun anotherFunction() {
          // Do something
      }
  }
  </code></pre>
  <p>The <code>_this</code> type parameter's name is pretty self-explaining of its role, if A already has type parameters then _this should be added at the beggining of them, and any type expression of the form A&lt;T, U, V, ...&gt; should expand to A&lt;A, T, U, V, ...&gt;.</p>
  <p><code>this</code> as return type would require that <code>return this</code> and <code>return /* something that has this as type */</code> are the only <code>return</code> statements that are allowed, as we couldn't ensure that any other value is actually always of the same type as <code>this</code>.</p>
  <p>I propose <code>this</code> (what a great pun huh) because it has been several times that I felt a need for such a feature, but I'm unsure whether this is a good idea or not, if it is feasible, and if there actually are people that are interested.</p>
  <p>In either cases, thank you for reading, have a great day !</p>