Sorry for the noise - looks like you meant when passing around objects by
this type, not just creating objects.
On Friday, May 3, 2024 at 11:02:37 AM UTC-6 Kevin Chowski wrote:
> If you are just unhappy about the A and A* while using a literal for C:
> note that if you are willing/able to write
If you are just unhappy about the A and A* while using a literal for C:
note that if you are willing/able to write a wrapper function instead of
using a literal, type inference works well today:
func NewC[E any, P Settable[E]](val []E) C[E, P] {
return C[E, P]{Val: val}
}
var c = NewC([]A{1, 2,
On Mon, Apr 22, 2024 at 11:01 PM Jochen Voss wrote:
>
> This works, see my code below. Followup question: is there a way to refer to
> the new type without having to list both the element type and the pointer
> type separately?
Unfortunately there is not. At some point in the future the langu
Thank you both!
This works, see my code below. Followup question: is there a way to refer
to the new type without having to list both the element type and the
pointer type separately? Below I have to write C[A, *A], which looks
slightly ugly. And in my real application something like Creator
On Mon, Apr 22, 2024 at 9:54 PM Ian Lance Taylor wrote:
>
> On Mon, Apr 22, 2024 at 2:25 PM Jochen Voss wrote:
> >
> > Using generics, can I somehow write a constraint which says that *T
> > (instead of T) implements a certain interface? The following code
> > illustrated what I'm trying to do
On Mon, Apr 22, 2024 at 2:25 PM Jochen Voss wrote:
>
> Using generics, can I somehow write a constraint which says that *T (instead
> of T) implements a certain interface? The following code illustrated what
> I'm trying to do:
>
> type A int
>
> func (a *A) Set(x int) {
> *a = A(x)
> }
>
> typ
Using generics, can I somehow write a constraint which says that *T
(instead of T) implements a certain interface? The following code
illustrated what I'm trying to do:
type A int
func (a *A) Set(x int) {
*a = A(x)
}
type B string
func (b *B) Set(x int) {
*b = B(strconv.Itoa(x))
}
type C1 s
This is brought up in the release notes:
https://tip.golang.org/doc/go1.18#generics
The Go compiler only supports calling a method m on a value x of type
> parameter type P if m is explicitly declared by P's constraint interface.
> Similarly, method values x.m and method expressions P.m also are o
I have the following code snippet.
type workloadInterface interface {
*appsV1.Deployment | *appsV1.StatefulSet
}
.
.
.
func (a *adapter) processDepOrSSForSvc(client kubernetes.Interface,
ns, svcName, workloadName, svcVersionType string) {
switch svcVersionType {
c
On Tue, Jul 21, 2020 at 5:53 AM Manlio Perillo wrote:
>
> What about:
>
> package example(T1, T2)
>
> This declares T1 and T2 as package level types.
>
> import "example"(int, float)
>
> This imports the example package with T1 as int and T2 as float.
>
> The limitation is that you need to
What about:
package example(T1, T2)
This declares T1 and T2 as package level types.
import "example"(int, float)
This imports the example package with T1 as int and T2 as float.
The limitation is that you need to import the same package multiple times
for different T1 and T2.
Manlio
If you need different type parameters lists, use multiple groups:
package collection
generic (type T) (
type List struct {
root *Node(T)
}
type Node struct {
prev, next *Node(T)
}
func (l *List(T)) InsertAfter(after* Node(T))
)
generic (type T1, T2) (
MapList(l List(T1), mapFn func(value T1)
On Sat, Jul 18, 2020 at 4:00 AM Markus Heukelom
wrote:
>
> Concerning only the current proposal, is there a reason why we shouldn't
> allow specifying the parametric types for a whole bunch of functions / types
> at once?
>
> Like:
>
> generic (type T) (
>
> func Average(value []T) {...}
> func
Thanks for the answer.
Concerning only the current proposal, is there a reason why we shouldn't
allow specifying the parametric types for a whole bunch of functions /
types at once?
Like:
generic (type T) (
func Average(value []T) {...}
func Median(value []T) {...}
// etc
)
generic (type T1, T
On Fri, Jul 17, 2020 at 1:56 AM Markus Heukelom
wrote:
>
> The authors of the current generics proposal mention that they looked into
> doing generics only on package
> level:(https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#why-not-put-type-parameters-
The authors of the current generics proposal mention that they looked into
doing generics only on package level:(
https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#why-not-put-type-parameters-on-packages
)
I understand the reasons what it wasn't pursued f
16 matches
Mail list logo
