On Sunday, June 21, 2020 at 11:24:37 PM UTC-4, Ian Lance Taylor wrote:
>
> On Sat, Jun 20, 2020 at 8:08 PM T L <tapi...@gmail.com <javascript:>>
> wrote:
> >
> >
> >
> > On Saturday, June 20, 2020 at 3:08:42 PM UTC-4, David Finkel wrote:
> >>
> >>
> >>
> >> On Sat, Jun 20, 2020 at 11:03 AM T L <tapi...@gmail.com> wrote:
> >>>
> >>>
> >>>
> >>> On Saturday, June 20, 2020 at 10:21:56 AM UTC-4, Axel Wagner wrote:
> >>>>
> >>>> I would assume it's
> >>>>
> >>>> type MapConstraint(type K comparable, V interface{}) interface {
> >>>> type map[K]V
> >>>> }
> >>>>
> >>>> func F(type M MapConstraint(K, V), K comparable, V interface{}) (m M)
> {
> >>>> }
> >>>>
> >>>> Note that you are under no obligation to make use of a type-parameter
> if you don't need it.
> >>>
> >>>
> >>> I don't very understand this. Can a slice value be used as the
> argument of the F function?
> >>
> >> For that, I think you'd need the interface to be:
> >> type MapSliceConstraint(type K comparable, V interface{}) interface {
> >> type map[K]V, []V
> >> }
> >>
> >> I'm not quite sure how to eliminate the useless K type-param for
> slices, though.
> >>
> >> Note: the relevant draft design section is:
> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#type-parameters-in-type-lists
>
> >>
> >> Here's an almost working example:
> >> https://go2goplay.golang.org/p/qcdfl0tuHlb
> >>
> >> It looks like there's a bug in the type-parameter constraint checking
> because in the above example code, I get:
> >>
> >> type checking failed for main
> >>
> >> prog.go2:11:39: K does not satisfy comparable
> >>
> >> This, despite the type parameter definition literally requiring that K
> be comparable:
> >> func genLen(type T MapSliceConstraint(K, V), K comparable, V
> interface{})(collection T) int {
> >> return len(collection)
> >> }
> >> (example without a main() to reduce clutter:
> https://go2goplay.golang.org/p/1gqiYuDELuI)
> >
> >
> >
> > Thanks for making this example.
> >
> > However, it almost reach my upper limit understanding ability to get the
> implementation.
> > I looks some bad practices in using C++ template.
> >
> > Is it good to add a Kind list constraint? For example,
> >
> > type MapOrSlice interface {
> > kind map, []
> > }
>
> We've already decided in this design draft that we are not going to
> permit all possible constraints. Therefore, this is the kind of
> question that needs to be answered based on experience using real
> code. Do people want or need to write real code that permits
> declaring that some type parameter is a map or a slice, without
> knowing anything else about the type? I don't see how such
> information would be useful at all. Without knowing anything about
> the key or element types of the map/slice, it would be very difficult
> to use such a type parameter in any useful way. And quite apart from
> that, when is it useful for people to write a function that takes
> either a map or a slice, but nothing else? We need real examples of
> real code that people want to write, not theoretical ideas for code
> that people might in theory want to write. Thanks.
>
> Ian
>
One example is the above Print function example.
Another example I current get is to iterate and print
all the key and values of a container in a current format.
There should be more examples with this need I think.
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/a1d04f83-f688-4804-b602-48c385a5b874o%40googlegroups.com.
