You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This would reify the inheritance relationships, and enable certain uses of generics and would be source-generator friendly (like, I can generate my own __cast() "operator" methods).
Fields, which would have to be exposed as ref properties, might be best left out of the interfaces. Otherwise it would greatly increase friction for implementing and using them (hard to take the address of things).
The text was updated successfully, but these errors were encountered:
rickbrew
added
proposal
An issue that represents a proposed feature or change to the repo.
untriaged
An issue that has not been triaged by the repo maintainers.
labels
Dec 4, 2021
This idea could potentially go as far as every struct having a .Interface, but I think it's more appropriate to keep it limited to structs which either already have inheritance (e.g. OSVERSIONINFOW and IUnknown), or have multiple forms (e.g. SHELLEXECUTEINFO{32,64}W)
For example,
This would reify the inheritance relationships, and enable certain uses of generics and would be source-generator friendly (like, I can generate my own
__cast()
"operator" methods).Fields, which would have to be exposed as
ref
properties, might be best left out of the interfaces. Otherwise it would greatly increase friction for implementing and using them (hard to take the address of things).The text was updated successfully, but these errors were encountered: