1 // Copyright 2019 The Go Authors. All rights reserved.
2 // Use of this source code is governed by a BSD-style
3 // license that can be found in the LICENSE file.
4
5 // This file shows some examples of methods on type-parameterized types.
6
7 package p
8
9 // Parameterized types may have methods.
10 type T1[A any] struct{ a A }
11
12 // When declaring a method for a parameterized type, the "instantiated"
13 // receiver type acts as an implicit declaration of the type parameters
14 // for the receiver type. In the example below, method m1 on type T1 has
15 // the receiver type T1[A] which declares the type parameter A for use
16 // with this method. That is, within the method m1, A stands for the
17 // actual type argument provided to an instantiated T1.
18 func (t T1[A]) m1() A { return t.a }
19
20 // For instance, if T1 is instantiated with the type int, the type
21 // parameter A in m1 assumes that type (int) as well and we can write
22 // code like this:
23 var x T1[int]
24 var _ int = x.m1()
25
26 // Because the type parameter provided to a parameterized receiver type
27 // is declared through that receiver declaration, it must be an identifier.
28 // It cannot possibly be some other type because the receiver type is not
29 // instantiated with concrete types, it is standing for the parameterized
30 // receiver type.
31 func (t T1[[ /* ERROR must be an identifier */ ]int]) m2() {}
32
33 // Note that using what looks like a predeclared identifier, say int,
34 // as type parameter in this situation is deceptive and considered bad
35 // style. In m3 below, int is the name of the local receiver type parameter
36 // and it shadows the predeclared identifier int which then cannot be used
37 // anymore as expected.
38 // This is no different from locally re-declaring a predeclared identifier
39 // and usually should be avoided. There are some notable exceptions; e.g.,
40 // sometimes it makes sense to use the identifier "copy" which happens to
41 // also be the name of a predeclared built-in function.
42 func (t T1[int]) m3() { var _ int = 42 /* ERROR cannot use 42 .* as int */ }
43
44 // The names of the type parameters used in a parameterized receiver
45 // type don't have to match the type parameter names in the declaration
46 // of the type used for the receiver. In our example, even though T1 is
47 // declared with type parameter named A, methods using that receiver type
48 // are free to use their own name for that type parameter. That is, the
49 // name of type parameters is always local to the declaration where they
50 // are introduced. In our example we can write a method m2 and use the
51 // name X instead of A for the type parameter w/o any difference.
52 func (t T1[X]) m4() X { return t.a }
53
54 // If the receiver type is parameterized, type parameters must always be
55 // provided: this simply follows from the general rule that a parameterized
56 // type must be instantiated before it can be used. A method receiver
57 // declaration using a parameterized receiver type is no exception. It is
58 // simply that such receiver type expressions perform two tasks simultaneously:
59 // they declare the (local) type parameters and then use them to instantiate
60 // the receiver type. Forgetting to provide a type parameter leads to an error.
61 func (t T1 /* ERROR generic type .* without instantiation */ ) m5() {}
62
63 // However, sometimes we don't need the type parameter, and thus it is
64 // inconvenient to have to choose a name. Since the receiver type expression
65 // serves as a declaration for its type parameters, we are free to choose the
66 // blank identifier:
67 func (t T1[_]) m6() {}
68
69 // Naturally, these rules apply to any number of type parameters on the receiver
70 // type. Here are some more complex examples.
71 type T2[A, B, C any] struct {
72 a A
73 b B
74 c C
75 }
76
77 // Naming of the type parameters is local and has no semantic impact:
78 func (t T2[A, B, C]) m1() (A, B, C) { return t.a, t.b, t.c }
79 func (t T2[C, B, A]) m2() (C, B, A) { return t.a, t.b, t.c }
80 func (t T2[X, Y, Z]) m3() (X, Y, Z) { return t.a, t.b, t.c }
81
82 // Type parameters may be left blank if they are not needed:
83 func (t T2[A, _, C]) m4() (A, C) { return t.a, t.c }
84 func (t T2[_, _, X]) m5() X { return t.c }
85 func (t T2[_, _, _]) m6() {}
86
87 // As usual, blank names may be used for any object which we don't care about
88 // using later. For instance, we may write an unnamed method with a receiver
89 // that cannot be accessed:
90 func (_ T2[_, _, _]) _() int { return 42 }
91
92 // Because a receiver parameter list is simply a parameter list, we can
93 // leave the receiver argument away for receiver types.
94 type T0 struct{}
95 func (T0) _() {}
96 func (T1[A]) _() {}
97
98 // For now, a lone type parameter is not permitted as RHS in a type declaration (issue #45639).
99 // // A generic receiver type may constrain its type parameter such
100 // // that it must be a pointer type. Such receiver types are not
101 // // permitted.
102 // type T3a[P interface{ ~int | ~string | ~float64 }] P
103 //
104 // func (T3a[_]) m() {} // this is ok
105 //
106 // type T3b[P interface{ ~unsafe.Pointer }] P
107 //
108 // func (T3b /* ERROR invalid receiver */ [_]) m() {}
109 //
110 // type T3c[P interface{ *int | *string }] P
111 //
112 // func (T3c /* ERROR invalid receiver */ [_]) m() {}
113
View as plain text