"Walter" <walter@digitalmars.com> wrote in message news:9sh1ca$1pn2$2@digitaldaemon.com...

> > Suppose I have the following declaration:
> >     int* x, y;
> > Is y an int or a pointer to int?
>
> An int. I didn't break away from C on that one. I can be persuaded otherwise.

Yes, yes!
Should we start collecting votes for a petition? =)

> > Question #2: how do I access method Y() of class B from A.Y()
> > (since B.Y() will invoke method Y() of object C)?
>
> A.B.Y()

I mentioned it already, but...
What if class A contains variable B? Will the above code do
what we expect it to?

> > Suppose I have the following declaration:
> >     int* x, y;
> > Is y an int or a pointer to int?
>
> An int. I didn't break away from C on that one. I can be persuaded otherwise.

Persuade, persuade, persuade, persuade.  Is that enough, or do we need more?

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

Walter wrote:
> 
> "Pavel "EvilOne" Minayev" <evilone@omen.ru> wrote in message news:9sdigb$2715$1@digitaldaemon.com...
> > What is the default attribute for class members
> > (private/protected/public)?
> 
> Public. I always thought that C++'s way just made for annoying extra typing when banging out quick code. A production quality class should always say it explicitly.

I'd personally lobby for the default attribute be "compilererror". That's just me though.

_R

Walter wrote:
> 
> None of them. I intend to have it (the default D calling convention) unspecified, so the compiler will be free to use whatever works best for the code gen for that particular function. This makes interprocedural optimizations possible. I strongly dislike the pointless proliferation of calling conventions found in win32.

So any external code that calls into D code can only safely do so to a D function that is defined with a non-default calling convention? I guess that lets you control the entry points...

-RB

"Walter" <walter@digitalmars.com> wrote in message news:9sh1ca$1pn2$2@digitaldaemon.com...
>
> > What is the default attribute for class members
> > (private/protected/public)?
>
> Public. I always thought that C++'s way just made for annoying extra
typing
> when banging out quick code. A production quality class should always say
it
> explicitly.

Agreed.  I suppose inheritance is also by default public?

> > Suppose I have the following declaration:
> >     int* x, y;
> > Is y an int or a pointer to int?
>
> An int. I didn't break away from C on that one. I can be persuaded otherwise.

Since you're changing the type specifiers anyway... may as well fix this legacy crap.  I can't tell you how many times this has burned me.  If someone wants two different types of variables, s/he can make two separate declarations.  This goes hand-in-hand with the idea to keep the type specifier all together in one place, parseable right to left.  If you start letting people put part of the type off somewhere else, the problem comes back such that type specifiers aren't complete, and people get confused.

> Prefix it with the module name. Assume the module name is foo:
>
>     foo.X()

What if someone made a local variable or member function named foo also? Yes they're bad... maybe we could allow some syntax like this:

().X()

or

static.X()

Some way to unambiguously get to the "global" scope (current module).

Maybe you could import foo; again, right there in the function, which overrides the local foo.

> > So the following:
> >     class A
> >     {
> >         static void B() { ... }
> >     }
> >     A a;
> >     A::B();
> >     a.B();    // the same?
>
> Yes.

Are you saying that D supports use of the :: operator?

Sean

"Pavel "EvilOne" Minayev" <evilone@omen.ru> wrote in message news:9sglrt$1ae5$1@digitaldaemon.com...
> Optimizations are good, but what about assembler routines? I believe that order of arguments on stack is not really important since you can use their names instead, but who should clean the stack - callee or caller?

If you are writing assembler routines, the options are:
1) use the inline assembler, where you don't care about call/return
conventions
2) declare the external assembler function with C call/return conventions

> Concerning name mangling. Are you going to define a single scheme that must be used by each and any compiler, or is it implementation- defined?

I'll define a scheme and recommend that people use it, though it won't be part of the language spec.

"Russell Borogove" <kaleja@estarcion.com> wrote in message news:3BEC2016.D83E8ED3@estarcion.com...
> Walter wrote:
> > None of them. I intend to have it (the default D calling convention) unspecified, so the compiler will be free to use whatever works best for
the
> > code gen for that particular function. This makes interprocedural optimizations possible. I strongly dislike the pointless proliferation
of
> > calling conventions found in win32.
> So any external code that calls into D code can only safely do so to a D function that is defined with a non-default calling convention? I guess that lets you control the entry points...


Yes. <g>

I want to leave the door open for aggressive interprocedural optimizations.

"Pavel "EvilOne" Minayev" <evilone@omen.ru> wrote in message news:9sh2a9$1qsq$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:9sh1ca$1pn2$2@digitaldaemon.com...
> > > Suppose I have the following declaration:
> > >     int* x, y;
> > > Is y an int or a pointer to int?
> > An int. I didn't break away from C on that one. I can be persuaded otherwise.
> Yes, yes!
> Should we start collecting votes for a petition? =)

I'm more interested in compelling arguments  (!)


> > > Question #2: how do I access method Y() of class B from A.Y()
> > > (since B.Y() will invoke method Y() of object C)?
> > A.B.Y()
> I mentioned it already, but...
> What if class A contains variable B? Will the above code do
> what we expect it to?

A.super.Y()

"Sean L. Palmer" <spalmer@iname.com> wrote in message news:9sh8ic$233l$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:9sh1ca$1pn2$2@digitaldaemon.com...
> > > What is the default attribute for class members
> > > (private/protected/public)?
> > Public. I always thought that C++'s way just made for annoying extra
> typing
> > when banging out quick code. A production quality class should always
say
> it
> > explicitly.
> Agreed.  I suppose inheritance is also by default public?

Yes.

> > > Suppose I have the following declaration:
> > >     int* x, y;
> > > Is y an int or a pointer to int?
> > An int. I didn't break away from C on that one. I can be persuaded otherwise.
> Since you're changing the type specifiers anyway... may as well fix this legacy crap.  I can't tell you how many times this has burned me.  If someone wants two different types of variables, s/he can make two separate declarations.  This goes hand-in-hand with the idea to keep the type specifier all together in one place, parseable right to left.  If you
start
> letting people put part of the type off somewhere else, the problem comes back such that type specifiers aren't complete, and people get confused.

I think you're right.

> What if someone made a local variable or member function named foo also?

Don't do that. It doesn't seem to be a significant problem in C.