Open Ifuhao opened 2 weeks ago
@ijt @dmitris @cflewis @rsc please help me
Why does it matter? The type alias and its actual definition should be equivalent?
@rsc Because type alias is exported(types.MessageOptions), but actual definition has unexported class(types.message)
I understand now, thanks. The go/types API historically did not expose any information about aliases, so this is the best wire could do. The right answer is probably to make your alias not be an alias:
type MessageOptions func(*message) string
Because func(*message) string is an unnamed type, the language allows implicit conversions between that type and MessageOptions, so basically none of your code should need to change.
We are slowly rolling out support in go/types for having alias information; once that is settled it would probably not be too hard to fix wire if you wanted to.
Thanks, it works when I use
type MessageOptions func(*message) string
You can use
go bug
to have a cool, automatically filled out bug template, or fill out the template below.Describe the bug
The alias defined using the
type
keyword is not used during code generation; instead, the original type is used.To Reproduce
Let's make some changes to the journey program.
There are 2 packages: main and types
in the package types: there are two go files named message.go and greeter.go
message.go
greeter.go
in the package main, there is only one file named wire.go
wire.go
Then I ran the wire program to generate wire_gen.go.
wire_gen.go
Expected behavior
I expect types.MessageOptions to remain in wire_gen.go, rather than being translated to func(types.message)*.
Version
v0.6.0
Additional context
nothing