Skip to content

Latest commit

 

History

History
64 lines (44 loc) · 2.26 KB

LDM-2018-09-05.md

File metadata and controls

64 lines (44 loc) · 2.26 KB

C# Language Design Notes for September 5, 2018

Agenda

  1. Index operator: is it a unary operator?
  2. Compiler intrinsics

Discussion

Index operator

There are multiple questions here:

  1. Is the operator syntactically a unary operator?
  2. Is it a user-definable operator?
  3. Does it have the same precedence as other unary operators?
  4. Do members which do not exist implicitly exist anyway as an intrinsic?
  5. Does it have overloads? Is ^^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.

Compiler intrinsics

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:

  1. Don't allow instance &receiver.M form -- only types for instance methods e.g., &TypeName.M.
  2. Drop the separate declaration for the 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.
  3. Would like the calling convention, if used, present at the call site.