On Sat, Jun 20, 2020 at 8:08 PM T L <tapir....@gmail.com> 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
--
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/CAOyqgcV0h_enPJSHkx80D7SM-7vOSYKwQGJU6VdKvNjM_vLyRQ%40mail.gmail.com.
