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

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

"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?

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

"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

"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

"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.

"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.