• Roberto Mariottini (22/22) Mar 21 2002 Hello all,
• Richard Krehbiel (23/32) Mar 21 2002 warning,
• Russell Borogove (28/47) Mar 21 2002 Heh, that's how I code, even for a+b*c, where I'm 99.2%
• Pavel Minayev (22/43) Mar 21 2002 warning,
• Walter (21/40) Mar 21 2002 warning,
• Roberto Mariottini (19/38) Mar 22 2002 such
• Pavel Minayev (12/23) Mar 22 2002 It IS an error, only not every compiler might detect it. But it's not
• Walter (10/37) Mar 23 2002 It's always an error, but whether the compiler detects it or not is a

"Roberto Mariottini" <rmariottini lycosmail.com> writes:

Hello all,
I have still some unanswered questions:

 - Explicit parenthesis around && within ||, as GCC says. Not every
programmer knows that
    (a || b && c)  means (a || (b && c)). In this case GCC issues a warning,
what about D?
 - How is this handled in D:
    int i = 43;
    int j = function1(++i, i++);
 - Will 'final' or somethig be supported to prevent overloading of a method
in a derived
    class?
 - Will some support for automatic documentation of D programs be added?
 - Will some crash-exception-bug reporting utility be added?
 - Will arrays support defining a non-zero start index?
 - Will equality and assignment work by reference or by value?
 - Will explicit casts be needed in automatic conversions with possible loss
of
    precision? (unsigned->signed, double->int, and so on).
 - I know dfront will be open source. What about starting now a project at
   SurceForge?

Thanks in advance

"Richard Krehbiel" <rich kastle.com> writes:

"Roberto Mariottini" <rmariottini lycosmail.com> wrote in message
news:a7cmg3$gcu$1 digitaldaemon.com...
 Hello all,
 I have still some unanswered questions:

  - Explicit parenthesis around && within ||, as GCC says. Not every
 programmer knows that
     (a || b && c)  means (a || (b && c)). In this case GCC issues a

warning,
 what about D?

Not every programmer realizes in every case that (a + b * c) means (a + (b *
c)).  Maybe all operations should be strictly left-to-right with precedence
by explicit parentheses - um - NOT.

I think D should demand that programmers have a minimum level of competence.
If they don't, then there's VB.  Yes, I make mistakes too - in fact, I've
coded a+b*c expecting (a+b)*c, by mistake of course, and the context
(type-casting, pointer math) made it a lot more obscure.  But I didn't blame
the language, I fixed my mistake.

  - How is this handled in D:
     int i = 43;
     int j = function1(++i, i++);

No one who codes this knows what they are doing.  I don't care if they think
they do - they don't.  C leaves this undefined, and I think that's fine.  C
doesn't require a diagnostic, and neither should D, even when it's as
obvious as this, because there are hundreds of unobvious ways.

If you want to put "sequence points" between evaluation of function
arguments, I suppose that's okay, though you still shouldn't know which of
++i and i++ were evaluated first.  But woe unto D in the day that modern
compilers on advanced machines can dispatch multiple microthreads to
evaluate function arguments in parallel.

--
Richard Krehbiel, Arlington, VA, USA
rich kastle.com (work) or krehbiel3 comcast.net  (personal)

Russell Borogove <kaleja estarcion.com> writes:

Richard Krehbiel wrote:
 "Roberto Mariottini" <rmariottini lycosmail.com> wrote in message
 news:a7cmg3$gcu$1 digitaldaemon.com...
 
Hello all,
I have still some unanswered questions:

 - Explicit parenthesis around && within ||, as GCC says. Not every
programmer knows that
    (a || b && c)  means (a || (b && c)). In this case GCC issues a
 warning, what about D?

 
 Not every programmer realizes in every case that (a + b * c) means (a + (b *
 c)).  Maybe all operations should be strictly left-to-right with precedence
 by explicit parentheses - um - NOT.

Heh, that's how I code, even for a+b*c, where I'm 99.2%
sure of the precedence. I _always_ write a+(b*c) because
the next poor bastard who might be working on my code
might have had lousy teachers, or he might be hung over,
or might be being distracted by his office-mate muttering
something about a stapler and setting the building on
fire.

 Yes, I make mistakes too - in fact, I've
 coded a+b*c expecting (a+b)*c, by mistake of course, and the context
 (type-casting, pointer math) made it a lot more obscure. But I didn't blame
 the language, I fixed my mistake.

Say you intended (a+b)*c, and due to the contextual
obscurity, you wrote a+b*c. Assume you got away with it
for a while, because a was usually zero, or because the
exact answer wasn't important or wasn't checked closely.

Now I'm trying to reuse your code in a context where a
is usually nonzero or where the exact answer is more
important. It's very hard for me to realize that you've
made an error, because of that contextual obscurity --
far harder for me to find the error than for you to
avoid the error when you were writing that line of code.
in the first place. After all -- I hear you were a pretty
good programmer before you took off to Hawaii to enjoy
your retirement, so I should trust your code! It's probably
my mistake! It's probably a compiler bug! This code used
to work fine!

For this reason, I personally would be happy with a
compiler that always required parentheses to disambiguate
(Guess I should be using lisp or something). I don't
expect anyone else to agree, however.

-Russell B

"Pavel Minayev" <evilone omen.ru> writes:

"Roberto Mariottini" <rmariottini lycosmail.com> wrote in message
news:a7cmg3$gcu$1 digitaldaemon.com...

 Hello all,
 I have still some unanswered questions:

  - Explicit parenthesis around && within ||, as GCC says. Not every
 programmer knows that
     (a || b && c)  means (a || (b && c)). In this case GCC issues a

warning,
 what about D?

There is a strict operator precedence table in D, which states that && is
evaluated before ||. Every D programmer should be aware of it - or die...

...or just put brackets around expressions on his own; but don't force
others, who know what they do, to do so.

  - How is this handled in D:
     int i = 43;
     int j = function1(++i, i++);

Order in which arguments are evaluated is undefined, so is the
result of this code.

  - Will 'final' or somethig be supported to prevent overloading of a

method
 in a derived
     class?

Walter said "yes".

  - Will some support for automatic documentation of D programs be added?

As soon as somebody will make it.

  - Will some crash-exception-bug reporting utility be added?

Um, what?

  - Will arrays support defining a non-zero start index?

I doubt.

  - Will equality and assignment work by reference or by value?

Assignment is definitely by reference. Equality will most likely stay the
same
as well (I didn't see any Walter's comments on the topic, which usually
means
that you won't see it in D =))

  - Will explicit casts be needed in automatic conversions with possible

loss
 of
     precision? (unsigned->signed, double->int, and so on).

D is not Java, I guess.

  - I know dfront will be open source. What about starting now a project at
    SurceForge?

Why?

"Walter" <walter digitalmars.com> writes:

"Roberto Mariottini" <rmariottini lycosmail.com> wrote in message
news:a7cmg3$gcu$1 digitaldaemon.com...
  - Explicit parenthesis around && within ||, as GCC says. Not every
 programmer knows that
     (a || b && c)  means (a || (b && c)). In this case GCC issues a

warning,
 what about D?

It works as in standard C, i.e. no warnings or errors.

  - How is this handled in D:
     int i = 43;
     int j = function1(++i, i++);

That is an error in D, although the compiler successfully detecting all such
cases is impossible. The rule is it is an error to depend on order of
evaluation when order of evaluation is determined by the compiler.

  - Will 'final' or somethig be supported to prevent overloading of a

method
 in a derived
     class?

Probably. It's a bit up in the air at the moment.

  - Will some support for automatic documentation of D programs be added?

Yes, in the form that D can be embedded inside html documents. (It
approaches the problem from the opposite end as Javadoc does, which embeds
documentation inside D.)

  - Will some crash-exception-bug reporting utility be added?

What do you mean? Some automatic thing to email Digital Mars on a crash?

  - Will arrays support defining a non-zero start index?

It's a good idea, but it's not in the present spec.

  - Will equality and assignment work by reference or by value?

By value for primitive types and structs, by reference for arrays and
classes.

  - Will explicit casts be needed in automatic conversions with possible

loss
 of
     precision? (unsigned->signed, double->int, and so on).

Yes.

  - I know dfront will be open source. What about starting now a project at
    SurceForge?

I have no idea how to go about that.

Great questions, btw.

-Walter

"Roberto Mariottini" <rmariottini lycosmail.com> writes:

"Walter" <walter digitalmars.com> ha scritto nel messaggio
news:a7drb4$144p$1 digitaldaemon.com...
 "Roberto Mariottini" <rmariottini lycosmail.com> wrote in message
 news:a7cmg3$gcu$1 digitaldaemon.com...
  - How is this handled in D:
     int i = 43;
     int j = function1(++i, i++);

 That is an error in D, although the compiler successfully detecting all

such
 cases is impossible. The rule is it is an error to depend on order of
 evaluation when order of evaluation is determined by the compiler.

If I understand well it can be an error or not, depending on the compiler
implementation. I am right?

  - Will some support for automatic documentation of D programs be added?

 Yes, in the form that D can be embedded inside html documents. (It
 approaches the problem from the opposite end as Javadoc does, which embeds
 documentation inside D.)

Maybe this is the right direction.
I should try to write some real code to see how it appears.

  - Will some crash-exception-bug reporting utility be added?

 What do you mean? Some automatic thing to email Digital Mars on a crash?

Ok, my fault. My original question is: is a D program supposed to crash on
an error?
(for example a Java program is not). If yes, what about adding a consistent
error-reporting procedure for a D program? Just an idea.
I find difficult to track a program when it prints only "segmentation
fault".

  - Will arrays support defining a non-zero start index?

 It's a good idea, but it's not in the present spec.

D 1.1?

  - I know dfront will be open source. What about starting now a project


at
    SurceForge?

 I have no idea how to go about that.

Do you think it's a viable solution to start dfront as a public project,
developed
by the community, or to you is better to keep it "under control"?

Ciao

"Pavel Minayev" <evilone omen.ru> writes:

"Roberto Mariottini" <rmariottini lycosmail.com> wrote in message
news:a7eq42$1jme$1 digitaldaemon.com...

 If I understand well it can be an error or not, depending on the compiler
 implementation. I am right?

It IS an error, only not every compiler might detect it. But it's not
valid D.

 Ok, my fault. My original question is: is a D program supposed to crash on
 an error?
 (for example a Java program is not). If yes, what about adding a

consistent
 error-reporting procedure for a D program? Just an idea.
 I find difficult to track a program when it prints only "segmentation
 fault".

D tries to track most errors (out-of-memory, array bounds etc) and
raises exceptions accordingly; if you don't handle them, they
are printed to stderr and program aborts. I'm not sure if it handles
things like access violation and such, though.

 Do you think it's a viable solution to start dfront as a public project,
 developed
 by the community, or to you is better to keep it "under control"?

I'd suggest not to open it completely for now. Everybody has his own
understanding of the "right thing", and to get something consistent,
only one should control the project.

"Walter" <walter digitalmars.com> writes:

"Roberto Mariottini" <rmariottini lycosmail.com> wrote in message
news:a7eq42$1jme$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> ha scritto nel messaggio
 news:a7drb4$144p$1 digitaldaemon.com...
 "Roberto Mariottini" <rmariottini lycosmail.com> wrote in message
 news:a7cmg3$gcu$1 digitaldaemon.com...
  - How is this handled in D:
     int i = 43;
     int j = function1(++i, i++);

 That is an error in D, although the compiler successfully detecting all

 such
 cases is impossible. The rule is it is an error to depend on order of
 evaluation when order of evaluation is determined by the compiler.

 If I understand well it can be an error or not, depending on the compiler
 implementation. I am right?

It's always an error, but whether the compiler detects it or not is a
quality of implementation issue.


  - Will some crash-exception-bug reporting utility be added?

 What do you mean? Some automatic thing to email Digital Mars on a crash?

 Ok, my fault. My original question is: is a D program supposed to crash on
 an error?
 (for example a Java program is not). If yes, what about adding a

consistent
 error-reporting procedure for a D program? Just an idea.
 I find difficult to track a program when it prints only "segmentation
 fault".

Having a seg fault is good - I remember the bad old DOS days where an error
would silently scramble your hard disk.

  - Will arrays support defining a non-zero start index?

 It's a good idea, but it's not in the present spec.

 D 1.1?

I want to do 1.0 first <g>.

 Do you think it's a viable solution to start dfront as a public project,
 developed
 by the community, or to you is better to keep it "under control"?

I'm concerned the language will splinter off into too many directions before
it has a chance to "gel" if it goes open source too early.