https://github.com/shader-slang/slang
Revision e9bf8de3123563df6f2ca4d3b99291c6a8c99d5d authored by Tim Foley on 27 August 2020, 20:49:00 UTC, committed by GitHub on 27 August 2020, 20:49:00 UTC
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<This : ICounter>(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`.
1 parent bc0d0f9
Tip revision: e9bf8de3123563df6f2ca4d3b99291c6a8c99d5d authored by Tim Foley on 27 August 2020, 20:49:00 UTC
Enable simple extensions of interface types (#1521)
Enable simple extensions of interface types (#1521)
Tip revision: e9bf8de
File | Mode | Size |
---|---|---|
docs | ||
examples | ||
external | ||
extras | ||
prelude | ||
source | ||
tests | ||
tools | ||
.editorconfig | -rw-r--r-- | 937 bytes |
.gitattributes | -rw-r--r-- | 95 bytes |
.gitignore | -rw-r--r-- | 759 bytes |
.gitmodules | -rw-r--r-- | 774 bytes |
.travis.yml | -rw-r--r-- | 2.1 KB |
CODE_OF_CONDUCT.md | -rw-r--r-- | 3.1 KB |
LICENSE | -rw-r--r-- | 1.1 KB |
README.md | -rw-r--r-- | 7.4 KB |
appveyor.yml | -rw-r--r-- | 4.0 KB |
premake.bat | -rw-r--r-- | 120 bytes |
premake5.lua | -rw-r--r-- | 38.6 KB |
slang-com-helper.h | -rw-r--r-- | 4.8 KB |
slang-com-ptr.h | -rw-r--r-- | 4.8 KB |
slang-tag-version.h | -rw-r--r-- | 36 bytes |
slang.h | -rw-r--r-- | 129.5 KB |
slang.sln | -rw-r--r-- | 13.7 KB |
test.bat | -rw-r--r-- | 1.4 KB |
travis_build.sh | -rw-r--r-- | 460 bytes |
travis_test.sh | -rw-r--r-- | 435 bytes |
Computing file changes ...