Propose direct associated type access

spec-draft.rst

@@ -281,3 +281,37 @@ Oh, we could maybe do better but it would require some new machinery.
 * ``Member[T]``, when statically checking a type alias, could be treated as having some type like ``tuple[Member[KeyOf[T], object???, str], ...]``
 * ``GetAttr[T, S: KeyOf[T]]`` - but this isn't supported yet. TS supports it.
 * We would also need to do context sensitive type bound inference
+
+----
+
+
+=============================
+Direct associated type access
+=============================
+
+What we *really* want for this is to write::
+
+  class Member[N: str, T, Q: MemberQuals = typing.Never, D = typing.Never]:
+      type name = N
+      type tp = T
+      type quals = Q
+      type definer = D
+
+And then we could just write ``m.name`` and have it do the right thing. (Ties broken by MRO of course).
+This would be super nice.
+
+The problem is that if the LHS isn't already evaluated, we'll get back just an alias with no idea what the LHS was, and we won't be able to substitute in the variables.
+
+TODO: DECIDE
+
+Ideas:
+ 1. Have it only work if the LHS is an evaluated variable somehow. That is kind of unsatisfying.
+ 2. Use something other than ``type name =`` to do this. Like, ``name = associated_type(N)`` and have that be a descriptor.
+ 3. Add a decorator or base class that replaces the GenericTypeAliases with the descriptor from above.
+ 4. Make ``GenericTypeAlias`` a descriptor (do the above for testing).
+
+UPDATE: None of this works except maybe the first one, because the descriptor will get called on the *origin class* and not the instantiated ``_GenericAlias``.
+
+We could probably kind of make it work by having a descriptor and having the descriptor *walk the stack* and get the ``self`` from the ``_BaseGenericAlias.__getattr__`` stack frame but that is a horror show...
+
+Yury thinks we don't want to propose anything that requires much modifying of the descriptors...