Is there a way to eliminate the code repetition in the code?

275 views
Skip to first unread message

tapi...@gmail.com

unread,
Mar 20, 2022, 12:36:27 PM3/20/22
to golang-nuts


package main

type A interface {
        Ma()
}

type B interface {
        Mb()
}

type Ta struct { A }

type Tb struct { B }

func ConvertSliceToA[From A](vs []From) []A {
        var r = make([]A, len(vs))
        for i := range vs {
                r[i] = vs[i]
        }
        return r
}

func ConvertSliceToB[From B](vs []From) []B {
        var r = make([]B, len(vs))
        for i := range vs {
                r[i] = vs[i]
        }
        return r
}

func main() {
        var x [100]Ta
        var _ = ConvertSliceToA(x[:])
       
        var y [100]Tb
        var _ = ConvertSliceToB(y[:])
}

Ian Lance Taylor

unread,
Mar 20, 2022, 12:50:45 PM3/20/22
to tapi...@gmail.com, golang-nuts

Henry

unread,
Mar 21, 2022, 3:29:44 AM3/21/22
to golang-nuts
Perhaps something like this?
```go
func Convert[T, A any](src []T, converter func(T) A) []A {
        result := make([]A, len(src))
        for index, a := range src {
                result[index] = converter(a)
        }
        return result
}
```

tapi...@gmail.com

unread,
Mar 22, 2022, 9:00:40 AM3/22/22
to golang-nuts
On Monday, March 21, 2022 at 3:29:44 PM UTC+8 Henry wrote:
Perhaps something like this?
```go
func Convert[T, A any](src []T, converter func(T) A) []A {
        result := make([]A, len(src))
        for index, a := range src {
                result[index] = converter(a)
        }
        return result
}
```

It might reduce some code (surely not eliminate), but it is very ungraceful.

The current constraint design lacks of two abilities:
1. The ability of specifying a type argument must be an interface type.
2. The ability of specifying a type argument must not be an interface type.

I except an implementation like

func ConvertSlice[From implements(To), To interface](vs []From) []To {
        var r = make([]To, len(vs))

Ian Lance Taylor

unread,
Mar 22, 2022, 11:07:41 AM3/22/22
to tapi...@gmail.com, golang-nuts
On Tue, Mar 22, 2022 at 6:01 AM tapi...@gmail.com <tapi...@gmail.com> wrote:
>
>
>
> On Monday, March 21, 2022 at 3:29:44 PM UTC+8 Henry wrote:
>>
>> Perhaps something like this?
>> ```go
>> func Convert[T, A any](src []T, converter func(T) A) []A {
>> result := make([]A, len(src))
>> for index, a := range src {
>> result[index] = converter(a)
>> }
>> return result
>> }
>> ```
>> See https://play.golang.com/p/rq89Wposc-D
>
>
> It might reduce some code (surely not eliminate), but it is very ungraceful.
>
> The current constraint design lacks of two abilities:
> 1. The ability of specifying a type argument must be an interface type.
> 2. The ability of specifying a type argument must not be an interface type.
>
> I except an implementation like
>
> func ConvertSlice[From implements(To), To interface](vs []From) []To {
> var r = make([]To, len(vs))
> for i := range vs {
> r[i] = vs[i]
> }
> return r
> }

I think it would be simpler to look for a way to express that one type
parameter is convertible to another type parameter, as I suggested
earlier. I don't see a need to distinguish between interface and
non-interface types, or to introduce the notion of whether one type
parameter implements another.

Ian

tapi...@gmail.com

unread,
Mar 22, 2022, 11:50:24 AM3/22/22
to golang-nuts
Is it hard to add two predeclared constraints, convertibleFrom and convertibleTo, just like comparable?

Ian Lance Taylor

unread,
Mar 22, 2022, 12:09:24 PM3/22/22
to tapi...@gmail.com, golang-nuts
On Tue, Mar 22, 2022 at 8:50 AM tapi...@gmail.com <tapi...@gmail.com> wrote:
>
> Is it hard to add two predeclared constraints, convertibleFrom and convertibleTo, just like comparable?

They aren't like comparable, though. comparable is a simple interface
type that describes a type set. convertibleTo and convertibleFrom
describe a relationship between a pair of types. We have to think
about the case where you have T1 and T2, and you want T2 to be
convertible to T1, but you also want to express additional constraints
on both T1 and T2. And we'll probably need a new syntax that is
unlike any existing syntax.

So, yes, this is hard.

Ian
> --
> You received this message because you are subscribed to the Google Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/9d1029ae-95ff-42be-9ae1-5bff74f5111bn%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages