"Ben Cohen" <bc@skygate.co.uk> wrote in message news:9tl3ju$1jdj$1@digitaldaemon.com...
> On Fri, 23 Nov 2001 00:28:09 +0000, Walter wrote:
> > "Ben Cohen" <bc@skygate.co.uk> wrote in message news:9tfs9k$1uhi$1@digitaldaemon.com...
> >> Public imports are a bit like inheritance (and you don't make "public" the default attribute for class members).
> >
> > Actually, D does <g>. The idea is to minimize the fluff for quick & dirty programs, while providing the facilities for the more carefully engineered production code.
> Oh, I missed that -- so the keyword "public" would be redundant for class members?

It is the default, but is not redundant. For example, if you switch to private, with public you can switch back again.

> That means either that protected (say) should be the default for classes, or else my argument doesn't work any more, depending on which way you look at it.  ;)

<g>

"Pavel "EvilOne" Minayev" <evilone@omen.ru> wrote in message news:9slgrh$241h$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:9si4hs$2ved$3@digitaldaemon.com...
>
> > I'm more interested in compelling arguments  (!)
>
> Suppose we have the following code:
>
>     int*[]* x, y;
>
> "Old" way: x is pointer to array of pointers, y is an array of
>     pointers. The first asterisk applies to both, the second
>     is applied only to x. Not only it's weird, but just try to
>     define a _clear_ rule (say, for the specification) that
>     strictly defines meaning of asterisk.
>
> New way: both are pointers to array of pointers. Anything
>     that's on the left is part of the type and is applied to
>     all variables on the line, no special cases and
>     exceptions.
>
> I vote for the new one...

I think you're right.

Walter wrote:

> "Pavel "EvilOne" Minayev" <evilone@omen.ru> wrote in message news:9slgrh$241h$1@digitaldaemon.com...
> > "Walter" <walter@digitalmars.com> wrote in message news:9si4hs$2ved$3@digitaldaemon.com...
> >
> > > I'm more interested in compelling arguments  (!)
> >
> > Suppose we have the following code:
> >
> >     int*[]* x, y;
> >
> > "Old" way: x is pointer to array of pointers, y is an array of
> >     pointers. The first asterisk applies to both, the second
> >     is applied only to x. Not only it's weird, but just try to
> >     define a _clear_ rule (say, for the specification) that
> >     strictly defines meaning of asterisk.
> >
> > New way: both are pointers to array of pointers. Anything
> >     that's on the left is part of the type and is applied to
> >     all variables on the line, no special cases and
> >     exceptions.
> >
> > I vote for the new one...
>
> I think you're right.

Seconded!

You know, it seems like about half of the bugs mentioned in those PC-Lint ads descend from just this issue.  Let's kill it dead in D!

However, I'd like to make it even more stringent:  "A single declaration can create variables of only a single type."

Let's eliminate all the cousins of the above, such as:

     int*[]* x, y, *z;

This should be an error!  The "correct" form should require z to be on a separate line.

Pretty please?


-BobC

On Fri, 30 Nov 2001 04:31:11 +0000, Robert W. Cunningham wrote:

> Let's eliminate all the cousins of the above, such as:
> 
>      int*[]* x, y, *z;
> 
> This should be an error!  The "correct" form should require z to be on a separate line.

Yes, I agree with this, for several reasons.  It simplifies the language and makes reading the code easier.  I think there would be less confusion with the C syntax.

And you can rewrite the above declaration as:

    int*[] *x, y, *z;

This is admittedly foolish, but certainly not implausible.  It looks like x and z are of the same type when actually x and y are.  (Unless you count the space as a delimiter, which isn't nice.)

"Robert W. Cunningham" <rwc_2001@yahoo.com> wrote in message news:3C070B8E.984C6418@yahoo.com...
> Let's eliminate all the cousins of the above, such as:
>
>      int*[]* x, y, *z;
>
> This should be an error!  The "correct" form should require z to be on a separate line.

Yeah, that should be an error. -Walter

> >      int*[]* x, y, *z;
> >
> > This should be an error!  The "correct" form should require z to be on a separate line.

Yes: pointers are types.
so the '*' must be after the pointed type, NOT before the pointer name:

int* pointer;            <- correct
int *pointer;            <- NOT correct

so

int* p1,p2,p3;    <- correct, all are pointers

int *p1,p2,p3;    <- NOT correct

Roland

Roland wrote:

> int* p1,p2,p3;    <- correct, all are pointers
>
> int *p1,p2,p3;    <- NOT correct

Are you stating that it currently is a syntax error, or that you think it should be?

Certainly, the latter syntax is confusing...but I think that it is legal currently.  I would very much want to encourage the former syntax...but I would hate to make D more limiting than C when it comes to parsing the tokens.  A warning, perhaps?

--
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))) ]

Russ Lewis a écrit :

> Roland wrote:
>
> > int* p1,p2,p3;    <- correct, all are pointers
> >
> > int *p1,p2,p3;    <- NOT correct
>
> Are you stating that it currently is a syntax error, or that you think it should be?

Should be.
With the new style for pointer declaration there is no more use to let the '*'
front of the data name instead of back the pointed type.
So pointer declaration syntax is standard now:

Type    instance1[instance2,..];

If we considere for example 'int*' as a type.

Roland

The key issue to me here is the parsing of tokens.  As I understand C parsing,
whitespace is only used to delimit tokens which cannot be otherwise differentiated,
most notably strings of characters that make up keywords and identifiers.  Where the
differentiation is clear by the character sequence, whitespace is not needed.  What I
mean is that the following lines are all viewed as identical to the C compiler:
    int* ptr;
    int *ptr;
    int*ptr;

Each is parsed into four tokens: 'int' '*' 'ptr' ';'

In order to do what you suggest, we must put artificial and very un-C-like restrictions on the parser.  IMHO, that is very undesirable as is starts us down a path of special case rules and a buggy parser.  The syntax you suggest is good...I will use it in my D programs.  But I don't think that we can require it.

--
The Villagers are Online! http://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))) ]

Russ Lewis a écrit :

> The key issue to me here is the parsing of tokens.  As I understand C parsing,
> whitespace is only used to delimit tokens which cannot be otherwise differentiated,
> most notably strings of characters that make up keywords and identifiers.  Where the
> differentiation is clear by the character sequence, whitespace is not needed.  What I
> mean is that the following lines are all viewed as identical to the C compiler:
>     int* ptr;
>     int *ptr;
>     int*ptr;
>
> Each is parsed into four tokens: 'int' '*' 'ptr' ';'
>
> In order to do what you suggest, we must put artificial and very un-C-like restrictions on the parser.  IMHO, that is very undesirable as is starts us down a path of special case rules and a buggy parser.  The syntax you suggest is good...I will use it in my D programs.  But I don't think that we can require it.

I thought whitespaces were separators un C.
I agree the goal is not to add  special cases but to supress them.
What i suggested is to standardize the fact that all type information must be at the
left
of the instance name.
In the same spirit as arrays declaration:

int[] array_of_int_instance;        //D style, type is declared completely before instance name

instead of

int array_of_int_instance[];    //C style, from left to right: it is a 'int'  named 'array_of_int_instance' but in fact it is an array: '[]'

And standardize the fact that all instances declared at the right of the type
declaration, separated by ',' , should be
of this type:

int* p1,p2;                //D style: all type 'int*'

Instead of;

int *p1,p2;            // C style: mixed types. p1 is a 'int*' , p2 is a int


Pavel \"EvilOne\" Minayev a écrit :

> Suppose we have the following code:
>
>     int*[]* x, y;
>
> "Old" way: x is pointer to array of pointers, y is an array of
>     pointers. The first asterisk applies to both, the second
>     is applied only to x. Not only it's weird, but just try to
>     define a _clear_ rule (say, for the specification) that
>     strictly defines meaning of asterisk.
>
> New way: both are pointers to array of pointers. Anything
>     that's on the left is part of the type and is applied to
>     all variables on the line, no special cases and
>     exceptions.
>
> I vote for the new one...

Me too

Roland