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

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

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)

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?

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

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

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

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

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?

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

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

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?

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

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

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

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

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.