My code <https://go2goplay.golang.org/p/QP2REBLl5f5> shows that returning a
generic function might be desirable.
The Filter function in my code <goog_279225190> is as follows:
func Filter(
type T interface{},
Source Observable(T),
)(pred func(T) bool) Operator(T, T, Source, FilterObservable(T,
Source)) {
return func(source Source) ((FilterObservable(T, Source))) {
return FilterObservable(T, Source){source, pred}
}
}
Despite the truth that Source is a type parameter of Filter function, the
Filter function is actually returning a generic function. Source cannot be
deduced by only looking at the input parameter of Filter function.
在 2020年6月24日星期三 UTC+8上午12:56:48，rog写道：
>
>
>
> On Tue, 23 Jun 2020 at 17:33, <teeli...@gmail.com <javascript:>> wrote:
>
>> Imagine the following function definition, under the current proposal (I
>> believe this is correct):
>>
>>
>> func (s MyMap(K, V)) DoSomething(k K, v V) (func(type K Hashable) (k K) (V,
>> error)) {...}
>>
>>
> I don't think that's quite right. You can't have function values with type
> parameters.
>
> So I think your example could look more like this in practice:
>
> func (s MyMap(K, V)) DoSomething(k K, v V) func(K) (V, error) { ... }
>
> That doesn't seem too unreasonable to me FWIW. It reads nicely from left
> to right, and everything except that first (K, V) declaration is just as
> things are today.
>
> cheers,
> rog.
>
--
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/2863cb7a-4ba9-46b3-86e7-2043dfa1c9a7o%40googlegroups.com.
