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

Closed
zigo101 opened this issue Nov 12, 2019 · 6 comments
Closed

proposal: treat declared function names as type names #35535

zigo101 opened this issue Nov 12, 2019 · 6 comments
Labels
FrozenDueToAge LanguageChange Suggested changes to the Go language Proposal Proposal-FinalCommentPeriod v2 An incompatible library change
Milestone

Comments

@zigo101
Copy link

zigo101 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
Copy link
Contributor

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
@bcmills bcmills added v2 An incompatible library change LanguageChange Suggested changes to the Go language and removed Proposal labels Nov 12, 2019
@ianlancetaylor
Copy link
Contributor

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
Copy link

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.

@zigo101
Copy link
Author

zigo101 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
Copy link
Contributor

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.

@ianlancetaylor
Copy link
Contributor

There were no further comments.

@golang golang locked and limited conversation to collaborators Jan 6, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge LanguageChange Suggested changes to the Go language Proposal Proposal-FinalCommentPeriod v2 An incompatible library change
Projects
None yet
Development

No branches or pull requests

5 participants