Christoffer Lerno

Note that the cname doesn't have a limit, just the identifier name. In this case: `drawPatches:patchStart:patchCount:patchIndexBuffer:patchIndexBufferOffset:instanceCount:baseInstance:tessellationFactorBuffer:tessellationFactorBufferOffset:tessellationFactorBufferInstanceStride:` You'd probably do: `extern fn drawPatches(Patches* patches, NSInteger patchStart, NSInteger patchCount ... ) @cname("drawPatches:patchStart:patchCount:...")`...

Thoughts on 127 limit?

To build a different target from the first, give the name for it, so for example `c3c build server` `c3c build client`

Did this resolve your problem?

@mcmah309 Thank you for this proposal. TLDR; I need to reject it, but I really like how they work as being opt-in for usage, so that some types are "prepped"...

If it's just a hint, it will offer much fewer guarantees and seemingly be rather useless? I had written something similar with "managed" pointers back as an old idea, mostly...

What I'm always careful of is adding more annotations or "viral" annotations (such as the infamous "const" in the case of C). Do you have some slim version of this...

Yes, I've thought of this a little. See #1410 for example. Maybe `other_func!` could work as the syntax? Because yes, it's a pain.

Yes, about the syntax: ```c fn TriangleKind? get_triangle_kind(Triangle* triangle) { check_triangle(triangle)!; } //-- or fn TriangleKind? get_triangle_kind(Triangle* triangle) { check_triangle(triangle)!; } //-- or fn TriangleKind? get_triangle_kind(Triangle* triangle) { check_triangle(triangle)!; }...

This should now work, try it out.