Consider a "non-PreserveSig" codegen setting

[AArnott]

When methods return HRESULT, consider making their friendly overload return void or the retval parameter and having the method throw on errors.

[weltkante]

There are the occasional COM methods where distinguishing multiple different successful HRESULTs is required (most prominently S_OK vs. S_FALSE which could actually be modeled by a boolean return value if it were annotated in the metadata). Do you expect to annotate the APIs which may return more than S_OK ?

Also there are plenty of COM methods where "error" HRESULTs are actually normal non-exceptional code paths, so forcing this to go through the slow .NET Exception handling logic seems counterintuitive when most other design decisions of this library (currently) are for high performance.

[AArnott]

Great points, @weltkante. In fact I was just discussing this with @mikebattista yesterday.
This will first off be exposed an an option so if you want PreserveSig for the reasons you gave, you can have it. We're not sure what the default will be yet.
If you choose not to use PreserveSig because it commonly makes things better, but you want to select very specific APIs to leave PreserveSig turned on for, we think we'll support that too. Probably through a JSON array in NativeMethods.json where you can specify the full name (e.g. IEnumStrings.Next) of the interface member(s) you want PreserveSig left on for.

What do you think? Does that sound like the right set of options?

[weltkante]

If theres an option to be selective and get the best of both worlds that works for me. Definitely not worse than what you currently have to do when writing ComImport mappings.

[AArnott]

This was done in #194

[andrekoehler]

@AArnott Do we have to list each interface where we want [PreserveSig] applied manually in 'NativeMethods.json' or is there a way to enable [PreserveSig] by default for all COM interfaces?

[AArnott]

Yes, you have to list each interface or interface member. If you want it on for all generation, can you open a new issue to track that? It should be cheap enough to support. But also please explain why, since we are considering what we should do for the dotnet/pinvoke precompiled library version of this, where users will have to take what we precompile or be forced to use the source generator.