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: spec: support type inference on generic structs #61731

Open
matthewmueller opened this issue Aug 3, 2023 · 1 comment
Open

proposal: spec: support type inference on generic structs #61731

matthewmueller opened this issue Aug 3, 2023 · 1 comment
Labels
generics Issue is related to generics Proposal TypeInference Issue is related to generic type inference
Milestone

Comments

@matthewmueller
Copy link

matthewmueller commented Aug 3, 2023

(I couldn't find an existing issue for this, but if there is, feel free to close!)

Problem

There's some inconsistencies in the capabilities of type inference for generics.

With functions, type inference works beautifully:

func Accepts[In, Out any](json func(in In) (Out, error), html func(in In) error) http.Handler {
  // call appropriate function depending on Accepts header
}

type Input struct {}
type Output struct {}

func indexJson(in *Input) (Output, error) {
  // render json
}

func indexHtml(in *Input) error {
  // render html
}

// Usage
router.Get("/", Accepts(indexJson, indexHtml))

Structs also work, but they require you to explicitly pass in the generic types:

type Accepts[In, Out any] struct {
  JSON func(in In) (Out, error)
  HTML func(in In) error
}

func (a *Accepts) ServeHTTP(w, r) {
}

// Usage
router.Get("/", Accepts[*Input, Output]{indexJson, indexHtml})

It feels rather unfortunate that you need to explicitly set the [*Input, Output] when usage and even syntax is otherwise so similar.

Proposal

Support type inference on structs, allowing the following:

router.Get("/", Accepts{indexJson, indexHtml})

When the concrete types in indexJson and indexHtml don't line up, it's a type error.


Thanks for your consideration!

@gopherbot gopherbot added this to the Proposal milestone Aug 3, 2023
@ianlancetaylor ianlancetaylor changed the title proposal: Support type inference on generic structs proposal: spec: support type inference on generic structs Aug 4, 2023
@ianlancetaylor ianlancetaylor added generics Issue is related to generics TypeInference Issue is related to generic type inference labels Aug 4, 2023
@ianlancetaylor
Copy link
Contributor

CC @griesemer

This seems to be suggesting that we can use a composite literal with a generic type and infer the type arguments from the elements of the composite literal. Seems doable at first glance. It might make a generic Pair type more useful, as one could write Pair{"a", 1} to get a Pair[string, int]. But I don't know that we actually want a generic Pair type.

We would need to consider all types of composite literals. For example, should this work for []Pair{{1, 2}, {3, 4}} ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
generics Issue is related to generics Proposal TypeInference Issue is related to generic type inference
Projects
Status: Incoming
Development

No branches or pull requests

3 participants