<feed xmlns='http://www.w3.org/2005/Atom'>
<title>slang.git/tests/language-feature/extensions/interface-extension.slang.expected.txt, branch master</title>
<subtitle>Making it easier to work with shaders</subtitle>
<id>https://git.yummers.dev/slang.git/atom?h=master</id>
<link rel='self' href='https://git.yummers.dev/slang.git/atom?h=master'/>
<link rel='alternate' type='text/html' href='https://git.yummers.dev/slang.git/'/>
<updated>2020-08-27T20:49:00+00:00</updated>
<entry>
<title>Enable simple extensions of interface types (#1521)</title>
<updated>2020-08-27T20:49:00+00:00</updated>
<author>
<name>Tim Foley</name>
<email>tfoleyNV@users.noreply.github.com</email>
</author>
<published>2020-08-27T20:49:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.yummers.dev/slang.git/commit/?id=e9bf8de3123563df6f2ca4d3b99291c6a8c99d5d'/>
<id>urn:sha1:e9bf8de3123563df6f2ca4d3b99291c6a8c99d5d</id>
<content type='text'>
The big picture here is that an `extension` can now apply to an interface type and provide convenience methods for all types that implement that interface. Suppose you have an interface for counters:

    interface ICounter { [mutating] void add(int val); }

and a type that implements it:

   struct SimpleCounter : ICounter { int _state = 0; ... }

If a common operation in your codebase is to increment a counter by adding one, you would be faced with the problem of either:

* Add the `increment()` operation to `ICounter`, and force every implementation to implement the new requirement

* Add the `increment()` operation to concrete counter types as needed, and thus not be able to use it in generic code

* Make `increment()` a global ("free") function, and force clients of counters to have to know which operations use member syntax (`c.add(...)`) and which use global function call syntax (`increment(c)`).

The whole idea of `extension`s is to allow for another option that is better than all of the above:

    extension ICounter { [mutating] void increment() { this.add(1); } }

The core of the implementation is relatively straightforward, and consists of two complementary pieces.

The first piece is that when emitting a concrete IR entity (function/type/whatever) we treat any enclosing `interface` type (or `extension` thereof) a bit like an enclosing `GenericDecl`, and introduce an `IRGeneric` to wrap things. The generic `IRGeneric` has parameters representing the `This` type for the interface, along with the witness table that shows how `This` conforms to the interface itself.

We thus end up with an IR version of `increment()` something like:

    void increment&lt;This : ICounter&gt;(This this) { this.add(1); }

The second (complementary) fix is that when there is code that references this `increment()` operation, we don't treat it like an interface requirement (look up based on its key), and instead treat it like a generic (since that is how it is lowered now) and speciaize it to the information we can glean from the `ThisTypeSubstitution`.

A related fix that is required here is that within the body of `increment`, when we perform `this.add`, we need to ensure that the lookup of `add` in the base interface properly takes into account the subtype relationship (`This : ICounter`) and encodes it into the lookup result, so that we get `((ICounter) this).add`, and properly generate code that looks up the `add` method in the witness table for `This`.</content>
</entry>
</feed>
