-
Notifications
You must be signed in to change notification settings - Fork 811
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
Known Issue: customtype that is another protocol buffer message with gogoprotobuf generated functions and methods is not supported #125
Comments
This should fix your issue Thank you for the idea for the fix :) |
The issue is still there:
Can we make Equal to have a concrete parameter type instead of empty interface? It will check everything on compile-time at least) |
If a type is specified as the parameter an Equaler interface is not possible.
|
It looks like its working |
To fix this will require a backwards incompatible change. Could you explain your use case, why must the repeated slice be a customtype and not just the message type? |
We use some custom type for IDs. It can be simplified to this: // Some interface which is guarantied to be comparable ([20]byte, for example)
type idData interface{}
type ID struct{
pref string
id idData
} We do not want to expose these fields, so the only way to directly use it in PB messages is to define it as a custom type. There is also a custom logic to deconstruct idData type from PB message. |
This should be possible? |
I haven't stated that custom types are not working, basically :) They are working pretty well. You commit fixed the issue for the except of asymmetry. But if it requires an backward-incompatible change, it's ok to close the issue now. |
Thank you for reporting. I look forward to your next report. |
Documented a31fa02 |
(Copied from #13)
There is an issue with this combination of options:
It will generate next code for M:
It will fail because
Equal
method will try to cast a parameter to*MyType
. So, the behavior ofEqual
method is asymmetric - it will try to pass anArr[i]
element, but their auto-generated versions assumes, that parameter will be a pointer to the type.The text was updated successfully, but these errors were encountered: