Why make any distinction between pointers and non pointers? Isn't the
(usual) point to allow the caller to decide upon instantiation?
We define a contract in terms of an unknown set of types and then let
whoever uses it fullfil the contract however they want?
On Tue, Jul 30, 2019, 21:57 <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/CAKOF695ayjMH7fE_OFd_gu414zxK6Co%3DWK0sNYwUvYr4SyD0hw%40mail.gmail.com.
