Walter Bright wrote:
> Sean Kelly wrote:
>> That seems like it should work.  Is the problem something to do with the order in which things are evaluated at compile-time?
> 
> It doesn't work because mixin is supposed to be a complete statement, not part of one.

Ah, I didn't know that.  Thanks.


SEan

Walter Bright escribió:
> Georg Wrede wrote:
>> Why not
>>
>>   extern(ecc) void function() foo;
>>
>> where ecc would resolve to Windows or C.
>>
>> This of course requires some tweaking of the compiler, but it might be worth it.
> 
> Do you mean "ecc" being a magic identifier that the compiler sets to Windows on Windows, and C otherwise? That might be a pretty good idea. Why "ecc", though? It doesn't jump out at me what it might mean.
> 
> How about "System" ?

I'm guessing this would be the default calling convention for the system. If the system was written in C++ (BeOS?), would it have to mean "extern(C++)"? If someone wrote an OS in D, would it just be "extern(D)"? Or would it just be specified that "System" means "Windows" on Windows and "C" everywhere else?

-- 
Carlos Santander Bernal

i like this idea !

/signed



Walter Bright schrieb:
> Georg Wrede wrote:
>> Why not
>>
>>   extern(ecc) void function() foo;
>>
>> where ecc would resolve to Windows or C.
>>
>> This of course requires some tweaking of the compiler, but it might be worth it.
>
> Do you mean "ecc" being a magic identifier that the compiler sets to Windows on Windows, and C otherwise? That might be a pretty good idea. Why "ecc", though? It doesn't jump out at me what it might mean.
>
> How about "System" ?

Carlos Santander wrote:
> I'm guessing this would be the default calling convention for the system. If the system was written in C++ (BeOS?), would it have to mean "extern(C++)"? If someone wrote an OS in D, would it just be "extern(D)"? Or would it just be specified that "System" means "Windows" on Windows and "C" everywhere else?

No, it would be what is necessary to interface to packages that pick pointless things like "Windows" calling conventions. If lots of C packages used "FooBar" calling conventions on XXX, then it would mean "FooBar" on that system.

Walter Bright escribió:
> Carlos Santander wrote:
>> I'm guessing this would be the default calling convention for the system. If the system was written in C++ (BeOS?), would it have to mean "extern(C++)"? If someone wrote an OS in D, would it just be "extern(D)"? Or would it just be specified that "System" means "Windows" on Windows and "C" everywhere else?
> 
> No, it would be what is necessary to interface to packages that pick pointless things like "Windows" calling conventions. If lots of C packages used "FooBar" calling conventions on XXX, then it would mean "FooBar" on that system.

Ok, thanks.

-- 
Carlos Santander Bernal

Walter Bright wrote:
> Sean Kelly wrote:
>> That seems like it should work.  Is the problem something to do with the order in which things are evaluated at compile-time?
> 
> It doesn't work because mixin is supposed to be a complete statement, not part of one. The XXX: forms a prefix, not a complete statement.

I thought "gotolabel:" would be a prefix but "private:" isn't.  Is there a big reason that distinction isn't true?

Walter Bright wrote:
> Georg Wrede wrote:
>> Why not
>>
>>   extern(ecc) void function() foo;
>>
>> where ecc would resolve to Windows or C.
>>
>> This of course requires some tweaking of the compiler, but it might be worth it.
> 
> Do you mean "ecc" being a magic identifier that the compiler sets to Windows on Windows, and C otherwise? That might be a pretty good idea. Why "ecc", though? It doesn't jump out at me what it might mean.
> 
> How about "System" ?

Please :) This looks like a great solution. And extern(System) is intuitive.

Walter Bright wrote:
> Georg Wrede wrote:
>> Why not
>>
>>   extern(ecc) void function() foo;
>>
>> where ecc would resolve to Windows or C.
>>
>> This of course requires some tweaking of the compiler, but it might be worth it.
> 
> Do you mean "ecc" being a magic identifier that the compiler sets to Windows on Windows, and C otherwise? That might be a pretty good idea. Why "ecc", though? It doesn't jump out at me what it might mean.
> 
> How about "System" ?

IMHO, extern(System) would be fantastic.

Mike Parker wrote:
> Walter Bright wrote:
>> Georg Wrede wrote:
>>> Why not
>>>
>>>   extern(ecc) void function() foo;
>>>
>>> where ecc would resolve to Windows or C.
>>>
>>> This of course requires some tweaking of the compiler, but it might be worth it.
>> 
>> Do you mean "ecc" being a magic identifier that the compiler sets to Windows on Windows, and C otherwise? That might be a pretty good idea. Why "ecc", though? It doesn't jump out at me what it might mean.
>> 
>> How about "System" ?
> 
> Please :) This looks like a great solution. And extern(System) is intuitive.

Yes, but what the Pascal convention?  And the windows API uses more then those three conventions, too.  This system isn't very flexible in case other platforms start using more than one convention.

Maybe Windows and Pascal could just 'degrade' into C on other platforms than windows?

Or allowing several possibilities:

extern (Windows, C)

Windows is picked on Windows, C on other platforms.  This allows you to control what happens.

On Mon, 09 Jul 2007 14:01:11 -0400, Walter Bright <newshound1@digitalmars.com> wrote:

> Georg Wrede wrote:
>> Why not
>>    extern(ecc) void function() foo;
>>  where ecc would resolve to Windows or C.
>>  This of course requires some tweaking of the compiler, but it might be worth it.
>
> Do you mean "ecc" being a magic identifier that the compiler sets to Windows on Windows, and C otherwise? That might be a pretty good idea. Why "ecc", though? It doesn't jump out at me what it might mean.
>
> How about "System" ?

I don't know; why not let it just be a string literal...

version(Windows)
	const char[] mylibcall = "Windows";
else
	const char[] mylibcall = "C";

extern(mylibcall) void function() foo;