From a8be079be38c56169487969dae71d6f659c0baf1 Mon Sep 17 00:00:00 2001
From: SolarScuffle-Bot <93509782+SolarScuffle-Bot@users.noreply.github.com>
Date: Thu, 4 Jan 2024 20:54:01 -1000
Subject: [PATCH] Update polymorphic-table-types.md

---
 docs/polymorphic-table-types.md | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/docs/polymorphic-table-types.md b/docs/polymorphic-table-types.md
index bfa72c5..6e9373d 100644
--- a/docs/polymorphic-table-types.md
+++ b/docs/polymorphic-table-types.md
@@ -10,7 +10,7 @@ The goal of this RFC is furthering type-safety and type-representation, especial
 
 At a type level, luau functions and tables are homomorphic as type mappings. One can view a table as a function mapping its keys to its values, or a function as a table with inputs as keys and outputs as values. This change resolves the hole left behind implementing polymorphic functions while excluding polymorphic tables, forcing type-safe applications to prefer functions over tables as maps.
 
-### General Accessor Pattern
+### General Indexer Pattern
 
 At an application level, the current workaround for this is to wrap the table in a function getter like so:
 
@@ -47,7 +47,7 @@ At this point if one is not satisfied with the extra baggage that goes behind a
 
 This proposal targets users already neck-deep in the type-system supporting libraries and tools, unable to achieve safety without compromising performance or their api and affecting thousands of users, or the occasional type-savvy user getting that perfect type for their data structure and feeling accomplished.
 
-### Specific Accessor Pattern
+### Specific Indexer Pattern
 
 We'll demonstrate using a minified ECS api from a library currently in production, getting components from an entity. This library depends on accessing components from tables using their constructors as indexers. The constructors contain the type information of the component, so it is theoretically possible to infer the type of the resulting component from the constructor, but this is not possible as of now because polymorphic tables don't exist.
 
@@ -94,7 +94,7 @@ We've lost our type information of `a` and `b` in the last table step!
 
 We propose naturally extending this type-mapping capability to tables in the backwards-compatible form `<T>{ [F<T>]: G<T> }`. We recycle our familiar syntax of polymorphic functions and use them in a very similar fashion. If one understands polymorphic functions, they will understand this as well. It is backwards compatible as it is currently invalid syntax.
 
-### General Accessor Solution
+### General Indexer Solution
 
 To rewrite our previous code examples using the new type:
 
@@ -109,7 +109,7 @@ type A = <T>{ [F<T>]: G<T> }
 type B = <T>(F<T>) -> G<T>
 ```
 
-### Specific Accessor Solution
+### Specific Indexer Solution
 
 Back to the ECS example, we change the type of `components` to be what it should have been all along:
 
@@ -148,7 +148,7 @@ In order for T to be inferable, it must appear in the argument of a function or
 ```
 
 ### Indexers
-At the time of this RFC, table types only support a single accessor excluding string keys. This is as complex as a table may be:
+At the time of this RFC, table types only support a single indexer excluding string keys. This is as complex as a table may be:
 
 ```lua
 <T, U...> {