Ah, thanks, I think I understand now. AIUI this would essentially require
that the author of a generic function or type would have to write a
contract to specifically allow or disallow pointer/value receivers to
satisfy the contract?
I personally don't really like the idea of putting that decision on the
implementer of a generic type or function - for pretty much the same reason
I don't want to know whether an interface-implementation uses pointer or
value receivers. All I (the implementer of a function taking the interface)
care is that they satisfy the API I require. I can't tell you (the
implement of that interface) whether you should do that via a pointer, a
basic type, an empty struct or a slice.
So IMO it's fine, for all operations I could wish to do with a pointer
(channel, slice, map…) to explicitly put that in my function signature.
Method calls are kind of an exception to that though - I still only care
about being able to call that method, just like with interfaces, but to do
that I *need* to know whether it's a pointer or value receiver. That's why
I think the exception from the design for that case is kind of justified
(even if a bit unfortunate) - specifically because it allows the
implementer of the generic function to ignore a distinction that is only
meaningful to its caller.
I do kind of agree with OP though, that it would seem more logical to just
require the caller to pass a pointer, when a pointer is required, just as
we do with interfaces. But weak opinions :)
On Tue, Jul 30, 2019 at 9:58 PM <alan.f...@gmail.com> wrote:
>
> On Tuesday, July 30, 2019 at 7:47:05 PM UTC+1, Axel Wagner wrote:
>>
>> On Tue, Jul 30, 2019 at 8:31 PM <alan...@gmail.com> wrote:
>>
>>> My suggestion was that you can't use a pointer type as a type parameter
>>> if the latter is subject to a contract.
>>>
>>
>> I'm not sure I understand you. Wouldn't that preclude using a generic map
>> with pointers as keys?
>>
>
> No, it wouldn't preclude that but the key would need to expressed as a *K
> rather than a K, if K were subject to a contract. As a pointer type it
> would automatically follow that *K was comparable.
>
>>
>>
>>> In the case you mention, the contract could be expressed as a
>>> disjunction of value and pointer methods:
>>>
>>> contract stringer(T) {
>>> T String() string, *T String() string
>>> }
>>>
>>
>> Currently, Disjunctions only apply to a single type. You can't form
>> expressions like this.
>> IMO that's a good restriction to maintain. Because the more powerful the
>> contract language becomes, the harder it'll be to make it useful.
>>
>
> Well, currently you can't use *T as a method receiver type in a contract
> so this would be a necessary exception to that rule if my suggestion were
> adopted.
>
> However, I agree with your general point that the restriction should be
> maintained in all other circumstances.
>
>>
>>
>>> On the other hand and more generally, not knowing whether the type
>>> parameter represented a pointer or a value might lead to some awkward
>>> coding. For example, you wouldn't be able to de-reference the type argument
>>> as it might not be a pointer.
>>>
>>
>> If a generic function wants to de-reference an argument, it should
>> specify that as a pointer: func f(type T) (p *T)
>> This is the same as with slices, maps, channels, functions or any
>> composite type - you can't express "type parameter T should be a slice of
>> some kind", because you are instead expected to just specify []T if you
>> want a slice.
>>
>
> Yes, but if T happened to be a pointer to some type, then *T would be a
> double pointer to that type. As the design currently stands, you'd have no
> way of knowing whether T was a pointer or not unless the contract specified
> that it was one of the predefined types.
>
> What I was trying to suggest here is that it would be helpful in some
> circumstances to know whether T was or was not a pointer type which would
> be a by-product of my suggestion.
>
> Alan
>
>
> --
> 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/cb9b37fc-19d4-4d25-bac8-72da1ade20a5%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/cb9b37fc-19d4-4d25-bac8-72da1ade20a5%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAEkBMfHvNm9Azg1rHph5J4vmAEsz3ONWsQRFyry4yJXz%3DZiqAQ%40mail.gmail.com.
