Add native pointer overloads of methods that accept IntPtr about pinvoke HOT 12 CLOSED

CC: @vbfox

from pinvoke.

Yes we need a list of all the pro/cons.

On the list of languages :

• ✅ C# (unsafe / T* foo)
• ✅ C++ (T* foo)
• ✅ F# (let foo : nativeptr<'T>)
• ✅ Boo (unsafe foo as T) didn't test myself but they had a unit test about unsafe (Language is now considered dead)
• 🔵 VB.Net
• 🔵 PowerShell
• 🎱 Nemerle (?)
• 🎱 IronSheme (?)
• 🎱 IronPython (?)

✅: Can call pointer exposing method
🔵: Can call IntPtr overload even if pointer version exists
⁉️ Doesn't support the IntPtr overload if the pointer version is present
🎱: Didn't find anythging / not searched

Also for the two overloads solutions it's pretty easy to codegen the IntPtr overloads if we write the pointer ones.

from pinvoke.

Can you add a legend for these icons above?

from pinvoke.

Ok I differentiated between VB that doesn't allow unsafe but can call the IntPtr version if also present with the same name and languages that support it natively.

Turn out that powershell is able to call an IntPtr version too if it exists (Just tested) with the same name so no problem here either.

Everything seem to point that the dual pointer/IntPtr is the good way to go, but we need to codegen it or it will be problematic pretty fast.

from pinvoke.

Also if we decide to go the "dual" way it's not really needed for a 0.x release, as we will only add overloads that aren't compatible and don't risk being picked by previously existing code.
But It would be nice to have that in 1.0 along with some variant of #70.

from pinvoke.

Thanks, @vbfox. I agree: let's go for dual mode. Until we have the code gen going, we should at least offer IntPtr versions so we don't block out use by VB.
Presumably when we start code gen that converts IntPtr to pointers, we can remove any manually created pointer overloads.

from pinvoke.

I just found out that unsafe code isn't allowed in C# iterator methods. That means that pointers aren't allowed in them, making it less convenient to call these methods even in a language that would otherwise allow it.

from pinvoke.

An open question on resolving some of these is what to do about struct fields that are pointers. Should they be IntPtr or a native pointer type? Can we perhaps use native pointers, but offer properties that expose them as IntPtrs for the VB folks?

from pinvoke.

Progress on fixing kernel32 is blocked on AArnott/CodeGeneration.Roslyn#1

from pinvoke.

Well, if we want to be consistent, struct fields should be native pointer types and the codegen should inject property wrappers of those fields.

So I am leaning toward native pointer type and properties that expose them as IntPtrs.

from pinvoke.

Agreed.

from pinvoke.

#130 tracks the struct fields now.

from pinvoke.