Update terminology in generics design docs (#610)

* implicit -> deduced
* type-type -> type-of-type
* extending/refining -> extending

Co-authored-by: Chandler Carruth <chandlerc@gmail.com>

docs/design/generics/goals.md

@@ -68,8 +68,8 @@ support templates in Carbon beyond interoperability with C++ templates.
 
 Generic functions and generic types will all take some "generic parameters",
 which will frequently be types, and in some cases will be
-[implicit or inferred](terminology.md#implicit-parameter) from the types of the
-values of explicit parameters.
+[deduced](terminology.md#deduced-parameter) from the types of the values of
+explicit parameters.
 
 If a generic parameter is a type, the generic function's signature can specify
 constraints that the caller's type must satisfy. For example, a resizable array

docs/design/generics/overview.md

@@ -75,7 +75,7 @@ Summary of how Carbon generics work:
     an unparameterized one. Functions can freely mix generic, template, and
     regular parameters.
 -   Interfaces can require other interfaces be implemented, or
-    [extend](terminology.md#extendingrefining-an-interface) them.
+    [extend](terminology.md#extending-an-interface) them.
 -   The `&` operation on type-of-types allows you conveniently combine
     interfaces. It gives you all the names that don't conflict.
 -   You may also declare a new type-of-type directly using
@@ -344,10 +344,10 @@ interface Iterable {
 }
 ```
 
-The `extends` keyword is used to
-[extend](terminology.md#extendingrefining-an-interface) another interface. If
-interface `Child` extends interface `Parent`, `Parent`'s interface is both
-required and all its methods are included in `Child`'s interface.
+The `extends` keyword is used to [extend](terminology.md#extending-an-interface)
+another interface. If interface `Child` extends interface `Parent`, `Parent`'s
+interface is both required and all its methods are included in `Child`'s
+interface.
 
 ```
 // `Hashable` extends `Equatable`.

docs/design/generics/terminology.md

@@ -20,7 +20,7 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
     -   [Definition checking](#definition-checking)
         -   [Complete definition checking](#complete-definition-checking)
         -   [Early versus late type checking](#early-versus-late-type-checking)
--   [Implicit parameter](#implicit-parameter)
+-   [Deduced parameter](#deduced-parameter)
 -   [Interface](#interface)
     -   [Structural interfaces](#structural-interfaces)
     -   [Nominal interfaces](#nominal-interfaces)
@@ -30,7 +30,7 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 -   [Adapting a type](#adapting-a-type)
 -   [Type erasure](#type-erasure)
 -   [Facet type](#facet-type)
--   [Extending/refining an interface](#extendingrefining-an-interface)
+-   [Extending an interface](#extending-an-interface)
 -   [Witness tables](#witness-tables)
     -   [Dynamic-dispatch witness table](#dynamic-dispatch-witness-table)
     -   [Static-dispatch witness table](#static-dispatch-witness-table)
@@ -41,7 +41,7 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 -   [Conditional conformance](#conditional-conformance)
 -   [Interface type parameters versus associated types](#interface-type-parameters-versus-associated-types)
 -   [Type constraints](#type-constraints)
--   [Type-type](#type-type)
+-   [Type-of-type](#type-of-type)
 
 <!-- tocstop -->
 
@@ -242,17 +242,17 @@ Late type checking is where expressions and statements may only be fully
 typechecked once calling information is known. Late type checking delays
 complete definition checking. This occurs for template dependent values.
 
-## Implicit parameter
+## Deduced parameter
 
-An implicit parameter is listed in the optional `[` `]` section right after the
+An deduced parameter is listed in the optional `[` `]` section right after the
 function name in a function signature:
 
-`fn` &lt;name> `[` &lt;implicit parameters> `](` &lt;explicit parameters `) ->`
+`fn` &lt;name> `[` &lt;deduced parameters> `](` &lt;explicit parameters `) ->`
 &lt;return type>
 
-Implicit arguments are determined as a result of pattern matching the explicit
+Deduced arguments are determined as a result of pattern matching the explicit
 argument values (usually the types of those values) to the explicit parameters.
-Note that function signatures can typically be rewritten to avoid using implicit
+Note that function signatures can typically be rewritten to avoid using deduced
 parameters:
 
 ```
@@ -261,7 +261,7 @@ fn F[T:$$ Type](value: T);
 fn F(value: (T:$$ Type));
 ```
 
-See more [here](overview.md#implicit-parameters).
+See more [here](overview.md#deduced-parameters).
 
 ## Interface
 
@@ -336,10 +336,11 @@ function signatures can change from base class to derived class, see
 [covariance and contravariance in Wikipedia](<https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)>).
 
 In a generics context, we are specifically interested in the subtyping
-relationships between [type-types](#type-type). In particular, a type-type
-encompasses a set of [type constraints](#type-constraints), and you can convert
-a type from a more-restrictive type-type to another type-type whose constraints
-are implied by the first. C++ concepts terminology uses the term
+relationships between [type-of-types](#type-of-type). In particular, a
+type-of-type encompasses a set of [type constraints](#type-constraints), and you
+can convert a type from a more-restrictive type-of-type to another type-of-type
+whose constraints are implied by the first. C++ concepts terminology uses the
+term
 ["subsumes"](https://en.cppreference.com/w/cpp/language/constraints#Partial_ordering_of_constraints)
 to talk about this partial ordering of constraints, but we avoid that term since
 it is at odds with the use of the term in
@@ -401,9 +402,9 @@ A facet type is a [compatible type](#compatible-types) of some original type
 written by the user, that has a specific API. This API might correspond to a
 specific [interface](#interface), or the API required by particular
 [type constraints](#type-constraints). In either case, the API can be specified
-using a [type-type](#type-type). Casting a type to a type-type results in a
-facet type, with data representation matching the original type and API matching
-the type-type.
+using a [type-of-type](#type-of-type). Casting a type to a type-of-type results
+in a facet type, with data representation matching the original type and API
+matching the type-of-type.
 
 Casting to a facet type is one way of modeling compile-time
 [type erasure](#type-erasure) when calling a generic function. It is also a way
@@ -416,7 +417,7 @@ A facet type associated with a specific interface, corresponds to the
 Using such a facet type removes ambiguity about where to find the declaration
 and definition of any accessed methods.
 
-## Extending/refining an interface
+## Extending an interface
 
 An interface can be extended by defining an interface that includes the full API
 of another interface, plus some additional API. Types implementing the extended
@@ -600,13 +601,13 @@ express, for example:
 Note that type constraints can be a restriction on one type parameter, or can
 define a relationship between multiple type parameters.
 
-## Type-type
+## Type-of-type
 
-A type-type is the type used when declaring some type parameter. It foremost
+A type-of-type is the type used when declaring some type parameter. It foremost
 determines which types are legal arguments for that type parameter, also known
 as [type constraints](#type-constraints). For template parameters, that is all a
-type-type does. For generic parameters, it also determines the API that is
+type-of-type does. For generic parameters, it also determines the API that is
 available in the body of the function. Calling a function with a type `T` passed
-to a generic type parameter `U` with type-type `I`, ends up setting `U` to the
-facet type `T as I`. This has the API determined by `I`, with the implementation
-of that API coming from `T`.
+to a generic type parameter `U` with type-of-type `I`, ends up setting `U` to
+the facet type `T as I`. This has the API determined by `I`, with the
+implementation of that API coming from `T`.