Custom calling conventions

[Paulo Pinto]

I think this fails in the same trap as extern "language" in C++.

Besides C and C++, I think the only variation I saw so far for the 
language part has been fortran, and cannot recall anylonger in what
compiler it was.

In C++'s case, since it is implementation defined, most compiler vendors
did not bother to support more than what the standard specifies (C and C++).

In you proposal, how to keep the feature portable across D implementations?

If you make it part of D language specification, which languages would 
be the chosen ones to be made available in any D compiler?

How to garantee correct interoperability (ABI) with other languages? 
After deciding the set of chosen languages, which compilers/runtimes 
would be the lucky ones?

--
Paulo

Am 21.02.2012 13:29, schrieb Manu:
> On 21 February 2012 14:13, Daniel Murphy <yebblies at nospamgmail.com
> <mailto:yebblies at nospamgmail.com>> wrote:
>
>     Why can't you do that with existing language features?
>
>     alias JniExternFunc!(void function(int)) someJNIFuncYouWantToCallFromD;
>     mixin JniExportFunc!(&dFuncYouWantToCallUsingJNI);
>
>     Where the templates generate the wrapper code/calling convention arg
>     shuffle
>     for each function.
>
>
> You could, but that's really ugly. I did make the point in my OP that it
> can be hacked right now, but I also listed the benefits of making it a
> proper feature:
>   1. It would be very neat and tidy. Clarity and readability is
> important for code longevity.
>   2. Ease of refactoring/delegation to scripts without refactoring all
> the calling code throughout your app (this is real, I have done this on
> many occasions)
>   3. Declaring functions in the regular way, and annotating them with
> various properties (const/pure/etc) allows all the usual type safety and
> optimisation potentials available to the language.
>       As far as the compiler is concerned, it is a real and normal
> function call. All surrounding code gen/optimisations are still
> applicable, the language will simply substitute the marshalling function
> at the final step of the call.
>   4-ish. It actually seems relatively simple to implement... and it's
> not a breaking change. I can't really see any down sides.