I'm for this.  The IDE could auto insert braces.

Sean

"Roberto Mariottini" <rmariottini@lycosmail.com> wrote in message news:aclmhe$jit$1@digitaldaemon.com...
>
> "C.R.Chafer" <blackmarlin@nospam.asean-mail.com> wrote in message news:aclb1b$8rh$1@digitaldaemon.com...
> >
> > I disagree - the language should be internally consistant,  therefore anywhere where block statements are permissable it should be possible should be possible to be replace them with a singe statement - even if
the
> > result is less than perfect,  as in this case.
>
> Sure, then we can apply it to functions:
>
> int func(int x, int y, int z) return x+2*y+3*z*x;
> void func2(int x, int *y) *y = func(x, x+*y, x-*y);
>
> Or to switch:
>
> switch(number)    case 1:    return 0;
>
> Good. And what about structs:
>
> struct Astruct
>    int i;
>
> Beautiful. :-(
> I vote for mandatory brackets everywhere (so the language would be
> internally consistant).
>
> Ciao.

> I vote for mandatory brackets everywhere (so the language would be
> internally consistant).

Had I designed the language that would have been the case,  however the language was designed to be like C - and therefore the block / statement rule - special cases are bad and lead to gotchas in the language,  D so far seems to be good at avoiding these so why should the try .. finally be different from the if .. else statement?  After all you are not required to omit the braces.

As for your example with the switch statement,  you use two statements and therefore require a block,  but for the function definitions I see no reason why that syntax should be invalid (and writing it this way should simplify that implementation of the parser).

C 2002/5/24

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:aclt0n$pm0$1@digitaldaemon.com...

> I'm for this.  The IDE could auto insert braces.

The Only True IDE Is Command Line! (tm)

I just HATE code with unnecessary braces. I understand why you want 'em. But let me write MY code in a way I want to see it.

"Roberto Mariottini" <rmariottini@lycosmail.com> wrote in message news:aclmhe$jit$1@digitaldaemon.com...

> Sure, then we can apply it to functions:
>
> int func(int x, int y, int z) return x+2*y+3*z*x;
> void func2(int x, int *y) *y = func(x, x+*y, x-*y);

Yes, why not? It would be a useful feature for property gettors & settors:

    void width(int w) width = w;
    int width() return width;

Unfortunately, it cannot be done, due to the ambiguity between forward declaration and empty statement:

    void width();    // does it have a body consisting only of ;, or is it a
declaration?

So we _have_ to use braces here, to disambiguate.

Try-catch, on other hand, does not cause ambiguity.

> Or to switch:
>
> switch(number)    case 1:    return 0;

There needs to be some way for the compiler to find end of switch block. In your example, it does not know where the case ends. So, braces are required here.

> Good. And what about structs:
>
> struct Astruct
>    int i;

Again, why not? There is no ambiguity here, so I guess the compiler could treat struct declarations that way.

But even here, there's a difference. struct is a _declaration_, it's not a statement. if-else is a statement and is defined as:

    if (<condition>) <statement> else <statement>

Where "statement" is ANY statement. Since complex statement { } is just a way to group together simple statements, it suites as well. It has nothing to do with struct.

> Beautiful. :-(

Maybe not for you.

> I vote for mandatory brackets everywhere (so the language would be
> internally consistant).

I vote for NO mandatory brackets everywhere it can be allowed (and
maybe where it makes sence, since struct or class consisting of
one member is not something you're gonna use more than once a year =)):
that is, everywhere except for functions, switch, struct, class
and enum. In other words, I vote for what is in DMD today.

I don't really understand "consistency" here - why would anybody care
why braces around struct are required, not so for if blocks...
I care more about line count:

    if (flag)
        live();
    else
        die();

Short AND clear, as long as you indent everything properly. Why waste 4 more lines?

    if (flag)
    {
        live();
    }
    else
    {
        die();
    }

I don't understand... is it ANY better, clearer, easier to read than the first version?

"Pavel Minayev" <evilone@omen.ru> wrote in message news:acm1t1$tuu$1@digitaldaemon.com...
> Unfortunately, it cannot be done, due to the ambiguity between forward declaration and empty statement:
>
>     void width();    // does it have a body consisting only of ;, or is it
a
> declaration?

There would be no such conflict; see: http://www.digitalmars.com/d/statement.html#empty

Anyway, I vote for braces.

> I don't really understand "consistency" here - why would anybody care
> why braces around struct are required, not so for if blocks...
> I care more about line count:
>
>     if (flag)
>         live();
>     else
>         die();
>
> Short AND clear, as long as you indent everything properly. Why waste 4 more lines?

Nothing is wasted by a few more lines. In the old days, I never wrote a function more that 24 lines long because it didn't fit the screen. Likewise, lines was rarely longer than 80 character. Back then, the number of lines was valuable. Now, I adjust the window size to suit my needs.

Indenting is in my experience not to be relied to heavily on. I have seen it destroyed again and again. A common reason for this is #&%! tabs (there are others, such as carelessness). Different people use tools with different tab sizes, and sometimes they become silently expanded, thereby causing havoc for indenting. And when it happens, it probably does not even show because it still compiles fine. So it lives on and the source is maintained. It is changed from that point on, changed again and again, elsewhere in the file, without anyone noticing. Some day, somebody is going to maintain the code where the indeting was damaged many revisions ago. There, the trouble begins.

>     {
>         die();
>     }
>
> I don't understand... is it ANY better, clearer, easier to read than the first version?

It is easier and safer to maintain. And if used consistently, yes, it is also easier to read.


Regards,
Martin M. Pedersen

"Martin M. Pedersen" <mmp@www.moeller-pedersen.dk> wrote in message news:acm5gq$116p$1@digitaldaemon.com...

> Nothing is wasted by a few more lines. In the old days, I never wrote a

Nor anything is given. So why would you want something that just takes place and doesn't give anything?..

> Indenting is in my experience not to be relied to heavily on. I have seen
it
> destroyed again and again. A common reason for this is #&%! tabs (there
are
> others, such as carelessness). Different people use tools with different
tab
> sizes, and sometimes they become silently expanded, thereby causing havoc for indenting. And when it happens, it probably does not even show because it still compiles fine. So it lives on and the source is maintained. It is changed from that point on, changed again and again, elsewhere in the
file,
> without anyone noticing. Some day, somebody is going to maintain the code where the indeting was damaged many revisions ago. There, the trouble begins.

This has nothing to do with braces, though. Unindented code with braces
is just as unreadable as unindented code without. For the examples of
both, take a look at Phobos source - Walter seems to dislike the TAB key...
=)

> It is easier and safer to maintain. And if used consistently, yes, it is

How is it easier to maintain? I agree that you have to add braces whenever you want to insert another statement into the block, but you do it just once anyhow - when you type it first or when you see it's really needed.

> also easier to read.

HOW is it easier to read? For you, maybe. But personally, I really hate unneeded braces.

Once again, it's just a MATTER OF PERSONAL TASTE. It has nothing to do
with consistency, speed, safety, etc etc. It's just what one particular
person considers neater (or easier to read, whichever you prefer). But
even though most people seem to prefer to put braces everywhere, it's NOT
the reason to force other people to code in their style. You wanna code
it that way - NOTHING stops you from doing so. You work in a team - adopt
a standard to be used by all members of that team. Just don't decide
for other people, that might have opinion different from yours. As long as
it doesn't harm, at least. And does it?

Otherwise, I'll ask to forbid spaces used for indentation, and require
tabs to be used for this purpose always. Or maybe I'll claim that lines
should not be longer than 70 characters, and compiler should give an
error if line is any longer... heh! Or how about a mandatory space between
"if" and "(" (so "if (" is legal, while "if(" is not)? We could also
require braces around the return expression: "return (0)" instead of
just "return 0". Why, it's consistency - if/while/for all have braces,
so why not require the same for return? And then for throw? Especially
since assert requires braces...

>
> Once again, it's just a MATTER OF PERSONAL TASTE. It has nothing to do
> with consistency, speed, safety, etc etc. It's just what one particular
> person considers neater (or easier to read, whichever you prefer). But
> even though most people seem to prefer to put braces everywhere, it's NOT
> the reason to force other people to code in their style. You wanna code
> it that way - NOTHING stops you from doing so. You work in a team - adopt
> a standard to be used by all members of that team. Just don't decide
> for other people, that might have opinion different from yours. As long as
> it doesn't harm, at least. And does it?

I agree that it's about personal taste. I also don't like braces. I use them because they're needed, but if there could be another way to do it (like in Basic, where every block has a starting and ending sentence) I would do it that way (not like Pascal, because BEGIN and END are even worse than braces). But there's something about what you've said: braces DO affect speed. As far as I know, whenever a compiler finds a (, [, {, /*, or something like that, it has to look for ), ], }, */, or something, so it makes it slower. I'm not sure if D does the same.

>
> Otherwise, I'll ask to forbid spaces used for indentation, and require
> tabs to be used for this purpose always. Or maybe I'll claim that lines
> should not be longer than 70 characters, and compiler should give an
> error if line is any longer... heh! Or how about a mandatory space between
> "if" and "(" (so "if (" is legal, while "if(" is not)? We could also
> require braces around the return expression: "return (0)" instead of
> just "return 0". Why, it's consistency - if/while/for all have braces,
> so why not require the same for return? And then for throw? Especially
> since assert requires braces...
>

About tabs and not spaces, length of lines, etc., it's also about personal taste. Like you said, you can't decide for other people. And about the space after if, probably an IDE could do it. But it also depends on the code. For example,

bit a;
...
if(a) ...;

I think it's clear enough to add a space.

"Pavel Minayev" <evilone@omen.ru> wrote in message news:aclgbn$dso$1@digitaldaemon.com...
>
> Don't like it - don't use it. But let other people do what they want.
> By the way, the code above is not correct: there are TWO statements
> in each try-block (since declaration is also a statement), so
> curly braces are required

I'd have to dissagree (I don't know if the code is correct for D but
consider and if-else)

if (...) ...
    if (...) ...
        if (...) ...
        else ...
    else ...
else ...

(... = some code)

a try-finally should be considered one statement just as if-else.

> And it's not that awful. Consider something like this:
>
>     Foo foo = new Foo;
>     try
>         foo.bar();
>     finally
>         delete foo;

That looks good.

>
> And compare this to:
>
>     Foo foo = new Foo;
>     try
>     { foo.bar()
>     } finally
>     { delete foo;
>     }
>
> Now, which looks better? =) It's a matter of taste, after all.
>
>
>

"anderson" <anderson@firestar.com.au> wrote in message news:acmt64$1mru$1@digitaldaemon.com...

> I'd have to dissagree (I don't know if the code is correct for D but
> consider and if-else)
>
> if (...) ...
>     if (...) ...
>         if (...) ...
>         else ...
>     else ...
> else ...
>
> (... = some code)
>
> a try-finally should be considered one statement just as if-else.

No, no, I didn't mean that. Of course it should. But in your code, in the try block (not in the catch block!), you had two statements: declaration, and function call.

"Carlos" <carlos8294@msn.com> wrote in message news:acmhd7$1cur$1@digitaldaemon.com...

> braces). But there's something about what you've said: braces DO affect speed. As far as I know, whenever a compiler finds a (, [, {, /*, or something like that, it has to look for ), ], }, */, or something, so it makes it slower. I'm not sure if D does the same.

I doubt you will notice the difference even if you compile a 10000-liner on 80486. =)

> About tabs and not spaces, length of lines, etc., it's also about personal taste. Like you said, you can't decide for other people. And about the
space
> after if, probably an IDE could do it. But it also depends on the code.
For
> example,
>
> bit a;
> ...
> if(a) ...;
>
> I think it's clear enough to add a space.

Well, I do. That's my style. But I don't force other people to do the same. That's what I just wanted to say...