Introduce design doc for Span/ReadOnlySpan<T> marshalling #1103
Conversation
Finish the in-code collection marshalling support design doc.
jkoritzinsky
added
the
area-DllImportGenerator
designs/SpanMarshallers.md
Outdated
|
|
||
| <!-- | ||
| Idea: Extend the StructMarshalling proposal with a design for a generic collection-based marshalling pattern. That will enable outlining the Span/ReadOnlySpan/array/etc. marshallers while enabling developers to enable marshalling any collection type they want without us adding types to the generator. | ||
| --> |
There was a problem hiding this comment.
Examples of unmanaged APIs that would be good candidates for the generic collection-based marshaling patterns?
There was a problem hiding this comment.
Here's a few ideas I had for the patterns:
- Move arrays to use this pattern (intrinsic support in the generator)
- Span -> native array
- List -> linked-list
- This could be useful if for example the JIT exposed a linked list type across the JIT interface body and crossgen2 needs to use it.
- LLVM also has a few linked list types that LLVMSharp could use this with if they exposed those APIs
- Dictionary -> array of keys or Dictionary -> array of values
- One good example of this is the coreclr hosting API
- Dictionary -> array of key-value-pair structures
- The JVM's
JavaVMInitArgsoptionsfield is a good example of this one.
- The JVM's
- Win32
SAFEARRAYsupport could be implemented with this model forSAFEARRAYs containing a specific element type in theVARIANTs.
The nice part about this design is that one developer could provide a "marshal a Dictionary as an array of the keys" and someone else could provide a "marshal an object as the result of it's ToString method" and then a user who wants to pass a Dictionary down as the string values of its keys doesn't have to write a marshaller for the whole scenario. They'd only have to say "use the Dictionary keys marshaller for the dictionary, and use the ToString marshaller for the elements."
|
I've updated Design 2 to focus on contiguous collections and mention non-contiguous ones as an extension we can look at in the future but don't need to adopt today. |
|
This LGTM. The only thing I would like understand better would be #1103 (comment). I didn't find an answer to that but admit I could have missed it due to terminology. |
|
I added a blurb for that towards the end of the section (if theres a marshaller for
Does that answer your question? |
Yes. I was misinterpreting the utility here. I understand the proposal now. |
…timelab#1103) * First draft of the heart of the span marshalling design. Finish the in-code collection marshalling support design doc. * Apply suggestions from code review Co-authored-by: Aaron Robinson <[email protected]> * Feedback. * Empty spans will be marshalled as null. * Make the primary design in Design 2 be contiguous collection support. * pr feedback and add example stub. * Fix typo Co-authored-by: Aaron Robinson <[email protected]> Commit migrated from dotnet/runtimelab@1bc504d
This PR introduces a design doc for us to discuss how to implement marshalling support for
Span/ReadOnlySpan<T>marshalling.I started implementing Design 1, but when I started writing out the design doc, I realized the limitations of the design. I wrote up Design 2 as a proposal for handling the concept of "collection" marshallers so developers won't have to fork the DllImport marshaller to support default marshalling for generic collection-like types. This way, we could provide support for Span/ReadOnlySpan marshallers without fully inlining them into the generator iself and we can provide additional marshalers for Span and ReadOnlySpan without weird drawbacks and inconsistencies.