meetings/2018/LDM-2018-09-05.md
There are multiple questions here:
^^1 allowed? That would imply that there's an
overload which takes an index.Follow-up: is .. a binary operator?
Conclusion
Agreed that it's syntactically a unary operator. Also agreed that it is a
semantically treated as a unary operator that it is not user-definable. Right
now, we don't see a great need to add a second overload. There is a single
overload for int.
We're not strictly defining .. as a binary operator right now. It has its
own syntactic form.
Also, we're renaming '^' to the "hat" operator.
Proposal: https://github.com/dotnet/csharplang/blob/master/proposals/intrinsics.md
There is contention between using void* and some stronger typing, either a
delegate or some kind of function pointer syntax. The benefit of using a
pointer type is that it is always unsafe, which this feature requires if
there are no allocations (because an appdomain could unload and cause the
invocation to point to arbitrary memory).
For calli, there's a worry about moving the typing from the point of
retrieving a function pointer to the declaration of the target and calling
convention. The extern declaration, specifically, is disliked.
Does this only work for managed code or also for native code? Do we have to care about the calling convention?
Conclusion
We'd probably be willing to accept this in some form. We think the current proposal needs some work.
Some thoughts/suggestions:
&receiver.M form -- only types for instance methods
e.g., &TypeName.M.calli invocation. A special calling
form like _calli_stdcall(args, f) is suggested. We don't like signature
being declared somewhere other than the method definition or at the call site.