Skip to content

Add technical docs on generic interfaces codegen #1989

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

Open
wants to merge 2 commits into
base: fhl/cswinrt-3.0
Choose a base branch
from

Conversation

Sergio0694
Copy link
Member

This PR adds docs explaining in detail all codegen to handle generic collection interfaces in CsWinRT 3.0.

@Sergio0694 Sergio0694 added documentation Improvements or additions to documentation AOT labels May 15, 2025
Copy link
Member

@jevansaks jevansaks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Posting my comments but I got a little lost in this writeup so I think we need an in-person review of some of this if you want thoughtful feedback.


This type derives from `WindowsRuntimeObject`, which provides all the usual support for IDIC, generated COM interfaces, and more. If needed, these RCW types (one per generic interface) can also contain additional state necessary to properly map the Windows Runtime interface behavior to the managed one. This is the case for `IEnumerator<T>`, which is slightly different than `IIterator<T>`, for instance.

Next, an interface is needed for each "Methods" implementation, for each generic interface. For `IIterator<T>`, it looks like this:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was mostly with you until this point. "An interface is needed" -- why? How does this connect to the scenarios above? I assume there's some general-purpose C#/WinRT machinery that is trying to reach out for this, but when/where?

}
```

This is conceptually similar to `IWindowsRuntimeComWrappersCallback` (which is used for delegates and sealed runtime class names), with the main difference being that it is specialized for unsealed types (and interfaces). In this case, implementations need to know the runtime class name of the native object, to determine whether they can marshal it via the fast path using a statically visible RCW type (see below), or whether they should fallback to the logic to marshal arbitrary opaque object that is used when no static type information is available (which involves going through the interop type lookup to get the marshalling info, etc.).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pretend I don't know anything about the current C#/WinRT implementation in this regard. What do I need to know/care about to evaluate this proposal? :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
AOT documentation Improvements or additions to documentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants