Walter Bright wrote:
> 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.

By this argument, it could just as easily be called "Broken".  I am concerned that calling it "System" will encourage widespread use...which is a step in exactly what you said was the wrong direction.

Did you see the post about using strings for extern?  That seemed like an elegant solution to me:

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

extern(myExternAlias) void foo();

Chris Miller wrote:
> 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;

It's the old chicken-and-egg problem of forward references.

Don Clugston wrote:
> IMHO, extern(System) would be fantastic.

It's a kludge, but a very useful one. I'll fold it into the next update.

torhu wrote:
> Yes, but what the Pascal convention?

People who #ifdef their C code to use Pascal on one platform and C on another should be excommunicated, and their software should be stricken from all monuments.

"Walter Bright" <newshound1@digitalmars.com> wrote in message news:f70mvo$22e7$1@digitalmars.com...
>
> It's the old chicken-and-egg problem of forward references.

Mind elaborating?  I can't see how this is a forward reference issue.

Reply to Jarrett,

> "Walter Bright" <newshound1@digitalmars.com> wrote in message
> news:f70mvo$22e7$1@digitalmars.com...
> 
>> It's the old chicken-and-egg problem of forward references.
>> 
> Mind elaborating?  I can't see how this is a forward reference issue.
> 

extern(A) const char[] A = "foo";

but as long as you don't worry about symbol names untill you are making .o files that isn't a problem (I would think).

On Tue, 10 Jul 2007 16:55:47 -0400, BCS <ao@pathlink.com> wrote:

> Reply to Jarrett,
>
>> "Walter Bright" <newshound1@digitalmars.com> wrote in message
>> news:f70mvo$22e7$1@digitalmars.com...
>>
>>> It's the old chicken-and-egg problem of forward references.
>>>
>> Mind elaborating?  I can't see how this is a forward reference issue.
>>
>
> extern(A) const char[] A = "foo";
>
> but as long as you don't worry about symbol names untill you are making .o files that isn't a problem (I would think).

I think problems like that exist all over the place; just don't do it.

int foo = foo.init;


I would like to know what Walter is referring to too.

Jarrett Billingsley wrote:
> "Walter Bright" <newshound1@digitalmars.com> wrote in message news:f70mvo$22e7$1@digitalmars.com...
>> It's the old chicken-and-egg problem of forward references.
> 
> Mind elaborating?  I can't see how this is a forward reference issue. 

Sure. What if the string is a const string defined after it is used?

Reply to Walter,

> Jarrett Billingsley wrote:
> 
>> "Walter Bright" <newshound1@digitalmars.com> wrote in message
>> news:f70mvo$22e7$1@digitalmars.com...
>> 
>>> It's the old chicken-and-egg problem of forward references.
>>> 
>> Mind elaborating?  I can't see how this is a forward reference issue.
>> 
> Sure. What if the string is a const string defined after it is used?
> 

That is one thing I have never understood: why does lexical order ever (outside of statement lists e.i. function) ever cause an issue?

I would expect that all of these issues could be removed by having one pass over the AST find the symbols (without getting types or anything else). Then another pass starts filling them out by reclusively evaluating symbols.

The only issue I see right off involve non-determinism of some things like static asserts and ifs and how errors are found. But I think that that could be removed (or rendered irrelevant) for cases where errors aren't present.

Then again, my experience with compilers stops just barely after lexers.

However I /am/ genuinely interested in your thoughts on this.

BCS wrote:
> That is one thing I have never understood: why does lexical order ever (outside of statement lists e.i. function) ever cause an issue?

const string x = "abc" ~ foo;
const string foo = x[1..4];