Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: treat declared function names as type names #35535

Open
go101 opened this issue Nov 12, 2019 · 5 comments

Comments

@go101
Copy link

@go101 go101 commented Nov 12, 2019

so that function names can be used as embedded types:

package main

func Filter(x int) bool {
	return x & 1 == 0
}

type T struct {
	Filter
}

func main() {
	var f Filter = func(x int) bool {
		return x > 0
	}
	
	_ = f
}

Another benefit.

Not an essential feature, but it is a little interesting, so I created the proposal.

@bcmills

This comment has been minimized.

Copy link
Member

@bcmills bcmills commented Nov 12, 2019

The typeof keyword proposed in #34515 might be a bit clearer:

	var f typeof(Filter) = func(x int) bool {
		[…]
	}

or

	var f Filter.(type) = func(x int) bool {
		[…]
	}
@bcmills bcmills changed the title propsoal: treat declared function names as type names proposal: treat declared function names as type names Nov 12, 2019
@gopherbot gopherbot added this to the Proposal milestone Nov 12, 2019
@gopherbot gopherbot added the Proposal label Nov 12, 2019
@bcmills bcmills added Go2 LanguageChange and removed Proposal labels Nov 12, 2019
@gopherbot gopherbot added the Proposal label Nov 12, 2019
@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Nov 12, 2019

At https://blog.golang.org/go2-here-we-come Robert laid out some guidelines for language changes, including that a change should "address an important issue for many people." It's not clear to me that this meets that bar. I'm not even sure when someone would want to use this feature.

@beoran

This comment has been minimized.

Copy link

@beoran beoran commented Nov 14, 2019

You can already do this with the existing language features, like this example:

package main

import (
	"fmt"
)

type Filter func (int) bool

func (f Filter) Apply(in []int) []int {
	res := []int{}
	for _, v := range in {
		if f(v) {
			res = append(res, v)
		}
	}
	return res
}


func main() {
	arr := []int{7, 9, 3, 5}
	var filter Filter = func(i int) bool {
		return i > 6
	}
	
	res := filter.Apply(arr)	
	fmt.Printf("arr -> res: %v -> %v\n", arr, res)
}

https://play.golang.org/p/MmcSA6FwlbV

So yes, you need to write a function type definition and a function that matches it separately, but It would be confusing for a function definition to also be an implicit type definition.

@go101

This comment has been minimized.

Copy link
Author

@go101 go101 commented Nov 14, 2019

I forgot to mention another benefit of this proposal.
This proposal partially compensates for the regret that lack of supporting final error values in Go.
For example, we can use foo.ErrXXX as a final error value:

package foo

func ErrXXX() {}

func (ErrXXX) Error() string {
	return "ErrXXX"
}
@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Dec 3, 2019

This proposal doesn't seem to have much support and doesn't seem to solve an important problem. The suggestion from @bcmills seems more like Go if we want to make any changes in this direction. The comment above suggests that ErrXXX can be a constant error value, but this seems like a roundabout way to implement that. For these reasons, this is a likely decline. Leaving open for four weeks for final comments.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.