www.digitalmars.com         C & C++   DMDScript  

D - Sick of trying

reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Is there really any reason for the try keyword?  Seems to me that we can
drop it.  But if we do that, then we can also attach catch blocks to any
block, most interestingly function blocks, where you could chain
exceptions like somebody mentioned recently:

void foo()
{
   // stuff
}
catch(Exception e)
{
    throw FooFailedException("foo() failed", e);
       // chains "foo() failed" onto the exception chain
}

--
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))) ]
Nov 09 2001
next sibling parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Ack!  Just realized that my example has the MAJOR downside of concealing the
exception type...all Exceptions become FooFailedExceptions.

Somehow, chaining of exceptions should retain the original exception type,
IMHO.

--
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))) ]
Nov 09 2001
prev sibling next sibling parent reply "Sean L. Palmer" <spalmer iname.com> writes:
That sounds like a really great idea.  More flexible... less typing... one
less keyword... it's great!

Sean

"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3BEC19BB.D1D93828 deming-os.org...

 Is there really any reason for the try keyword?  Seems to me that we can
 drop it.  But if we do that, then we can also attach catch blocks to any
 block, most interestingly function blocks, where you could chain
 exceptions like somebody mentioned recently:

 void foo()
 {
    // stuff
 }
 catch(Exception e)
 {
     throw FooFailedException("foo() failed", e);
        // chains "foo() failed" onto the exception chain
 }
Nov 09 2001
parent reply "Pavel \"EvilOne\" Minayev" <evilone omen.ru> writes:
"Sean L. Palmer" <spalmer iname.com> wrote in message
news:9sh7p5$227v$1 digitaldaemon.com...


 That sounds like a really great idea.  More flexible... less typing... one
 less keyword... it's great!


This however adds additional job for the compiler of determining
which blocks can potentionally throw exceptions and which can't,
for optimization purposes I believe.

Other than that, I like the idea. Could really make the program
look neater, and less typing as well... kewl =)
Nov 09 2001
next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Pavel "EvilOne" Minayev" <evilone omen.ru> wrote in message
news:9sil27$85b$1 digitaldaemon.com...

 "Sean L. Palmer" <spalmer iname.com> wrote in message
 news:9sh7p5$227v$1 digitaldaemon.com...


 That sounds like a really great idea.  More flexible... less typing...




one

 less keyword... it's great!


 This however adds additional job for the compiler of determining
 which blocks can potentionally throw exceptions and which can't,
 for optimization purposes I believe.

 Other than that, I like the idea. Could really make the program
 look neater, and less typing as well... kewl =)



It does look like the try keyword is redundant. On the other hand, some
redundancy is useful for:

1) catching syntax errors
2) putting out a reasonable error message as to what might be wrong
3) making it easier for a person examining the code to understand the intent
of it

Consider this - if a language had no redundancy in it, then *any* random
sequence of characters is a valid program.

How much redundancy is just right is a matter of personal taste. I, for
instance, find Pascal to be unbearably wordy, and Java excessively wordy. D
will take its cues from C and C++ on the general style of wordiness.
Nov 10 2001
next sibling parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Walter wrote:


 It does look like the try keyword is redundant. On the other hand, some
 redundancy is useful for:

 1) catching syntax errors
 2) putting out a reasonable error message as to what might be wrong
 3) making it easier for a person examining the code to understand the intent
 of it

 Consider this - if a language had no redundancy in it, then *any* random
 sequence of characters is a valid program.

 How much redundancy is just right is a matter of personal taste. I, for
 instance, find Pascal to be unbearably wordy, and Java excessively wordy. D
 will take its cues from C and C++ on the general style of wordiness.


Fair points.  Frankly, I don't know whether try is a practical help or not.  I
would still lean toward removing it, but that's just my opinion.

--
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))) ]
Nov 12 2001
prev sibling parent "Scott Egan" <scotte tpg.com.aux> writes:
Do you know this is called entropy - the amount of infomation that can be
transfered with a given code base.

An entropy of 1 is as you indicated, random - aka white noise.  Every bit
has as much meaning as the next and so a single bit error ruins the whole
message.



"Walter" <walter digitalmars.com> wrote in message
news:9skeha$1dh9$1 digitaldaemon.com...

 "Pavel "EvilOne" Minayev" <evilone omen.ru> wrote in message
 news:9sil27$85b$1 digitaldaemon.com...

 "Sean L. Palmer" <spalmer iname.com> wrote in message
 news:9sh7p5$227v$1 digitaldaemon.com...


 That sounds like a really great idea.  More flexible... less typing...




 one

 less keyword... it's great!


 This however adds additional job for the compiler of determining
 which blocks can potentionally throw exceptions and which can't,
 for optimization purposes I believe.

 Other than that, I like the idea. Could really make the program
 look neater, and less typing as well... kewl =)



 It does look like the try keyword is redundant. On the other hand, some
 redundancy is useful for:

 1) catching syntax errors
 2) putting out a reasonable error message as to what might be wrong
 3) making it easier for a person examining the code to understand the


intent

 of it

 Consider this - if a language had no redundancy in it, then *any* random
 sequence of characters is a valid program.

 How much redundancy is just right is a matter of personal taste. I, for
 instance, find Pascal to be unbearably wordy, and Java excessively wordy.


D

 will take its cues from C and C++ on the general style of wordiness.
Apr 18 2004
prev sibling parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Pavel \"EvilOne\" Minayev wrote:


 "Sean L. Palmer" <spalmer iname.com> wrote in message
 news:9sh7p5$227v$1 digitaldaemon.com...


 That sounds like a really great idea.  More flexible... less typing... one
 less keyword... it's great!


 This however adds additional job for the compiler of determining
 which blocks can potentionally throw exceptions and which can't,
 for optimization purposes I believe.


As I understand it, the parser determines which blocks are caught blocks and
which are not.  You just change the parser definition file; removing try would
not affect the compiler itself at all.

--
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))) ]
Nov 12 2001
prev sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Along the same lines, can we remove the requirement of having {} around the
try blocks?  This seems reasonable to me:

foo()  // note that there is no trailing semicolon
    catch(ACertainException e)
    {
         bar();
     };  // this is the closing semicolon of the expression

--
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))) ]
Nov 12 2001
parent reply "Pavel \"EvilOne\" Minayev" <evilone omen.ru> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3BEFE4A2.C1B4968F deming-os.org...

 Along the same lines, can we remove the requirement of having {} around


the

 try blocks?  This seems reasonable to me:

 foo()  // note that there is no trailing semicolon
     catch(ACertainException e)
     {
          bar();
      };  // this is the closing semicolon of the expression


I suggested a similar thing not long ago. Walter's reply
wasn't that clear. =)
Nov 12 2001
parent reply Aaron <arh14 cornell.edu> writes:
I don't understand why people want to be able to write unclear programs
so much.  What is wrong with try { }?  Really, one should have to make a
good argument why NOT to force clarity, instead of having to argue for
clarity in the first place.  All these "features" make compilation,
analysis, and debugging harder.

Aaron

Pavel \"EvilOne\" Minayev wrote:

 
 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3BEFE4A2.C1B4968F deming-os.org...

 Along the same lines, can we remove the requirement of having {} around


 the

 try blocks?  This seems reasonable to me:

 foo()  // note that there is no trailing semicolon
     catch(ACertainException e)
     {
          bar();
      };  // this is the closing semicolon of the expression


 
 I suggested a similar thing not long ago. Walter's reply
 wasn't that clear. =)
Nov 19 2001
next sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Basically, my thought was that we already had some constructs (like function
bodies, or multiline if- or for- blocks) that required {}.  In some of these
cases, it only inhibits clarity (IMHO) to require an extra set of {} for the
try block.

Aaron wrote:


 I don't understand why people want to be able to write unclear programs
 so much.  What is wrong with try { }?  Really, one should have to make a
 good argument why NOT to force clarity, instead of having to argue for
 clarity in the first place.  All these "features" make compilation,
 analysis, and debugging harder.

 Aaron

 Pavel \"EvilOne\" Minayev wrote:

 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3BEFE4A2.C1B4968F deming-os.org...

 Along the same lines, can we remove the requirement of having {} around


 the

 try blocks?  This seems reasonable to me:

 foo()  // note that there is no trailing semicolon
     catch(ACertainException e)
     {
          bar();
      };  // this is the closing semicolon of the expression


 I suggested a similar thing not long ago. Walter's reply
 wasn't that clear. =)




--
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))) ]
Nov 19 2001
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3BF92D76.86D23089 deming-os.org...


 Basically, my thought was that we already had some constructs (like


function

 bodies, or multiline if- or for- blocks) that required {}.  In some of


these

 cases, it only inhibits clarity (IMHO) to require an extra set of {} for


the

 try block.


I wouldn't mind if _multiline_ try block would require braces around
it since it's the only way to tell the compiler that the block is
actually multiline. =) However, when the whole block contains just
a single statement, I don't understand why I have to use braces
while, say, if() or for() don't require me to.
Nov 19 2001
parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
One thing we'll have to consider if try is removed is how the try block
applies to loop constructs.  Consider this code:


for(int i = 0; i<10; i++)
{
   ...
}
catch(ExceptionFoo f)
{
  ....
}



Now, does the catch catch just one iteration of the loop, or the whole thing?
That is, is it equivalent to:

{
    for(...)
    {
        ...
     }
}
catch(...)
{
   ...
};


or is it:

for( ... )
{
    {
         ...
    }
    catch( ... )
    {
         ...
    }
}


I would tend to lean toward the latter....but is it obvious to an
inexperienced reader or coder?


Pavel Minayev wrote:


 I wouldn't mind if _multiline_ try block would require braces around
 it since it's the only way to tell the compiler that the block is
 actually multiline. =) However, when the whole block contains just
 a single statement, I don't understand why I have to use braces
 while, say, if() or for() don't require me to.


--
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))) ]
Nov 19 2001
prev sibling parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Aaron" <arh14 cornell.edu> wrote in message
news:3BF9131A.7AB53FBC cornell.edu...


 I don't understand why people want to be able to write unclear programs
 so much.  What is wrong with try { }?  Really, one should have to make a
 good argument why NOT to force clarity, instead of having to argue for
 clarity in the first place.  All these "features" make compilation,
 analysis, and debugging harder.


The C way of defining a block - {} - is supposed to be used freely.
Look, if you force the {}'s, then what's the first brace is used for?
Since every if() defines a new block by your proposal, the brace
is just useless since it tells compiler of something that it's already
aware of. As such, it's a waste of time and space. On other hand,
the ending } looks quite ugly alone, so you have to replace it by
something else, like PHP alternative syntax:

    if (condition):
        statements
    endif;

There is another issue, which, BTW, was discussed before. But I'll
still mention it. The else-if construct. In C, you'd write:

    if (cond1)
        ...
    else if (cond2)
        ...
    else if (cond3)
        ...
    else
        ...

Now if you require braces, you'll get:

    if (cond1)
        ...
    else { if (cond2)
        ...
    else { if (cond3)
        ...
    else {
        ...
    }}}

Now whichever you'd prefer?
Nov 19 2001
next sibling parent reply "Sean L. Palmer" <spalmer iname.com> writes:
 There is another issue, which, BTW, was discussed before. But I'll
 still mention it. The else-if construct. In C, you'd write:

     if (cond1)
         ...
     else if (cond2)
         ...
     else if (cond3)
         ...
     else
         ...

 Now if you require braces, you'll get:

     if (cond1)
         ...
     else { if (cond2)
         ...
     else { if (cond3)
         ...
     else {
         ...
     }}}

 Now whichever you'd prefer?


If the language merely treated "else if" as a special case, that wouldn't be
a problem.

Sean
Nov 20 2001
parent reply "Pavel Minayev" <evilone omen.ru> writes:
My final point:

If you think that braces make source code cleaner, then
use them in your programs. But don't force others to.
Let it be freedom of choice. I, personally, think that
small ifs without {}s look neater:

    if (health <= 0)
        Die();
    else
        Sound(painsound);

    --- vs ---

    if (health <= 0)
    {
        Die();
    }
    else
    {
        Sound(painsound);
    }
Nov 20 2001
parent reply Russell Borogove <kaleja estarcion.com> writes:
Pavel Minayev wrote:

 
 My final point:
 
 If you think that braces make source code cleaner, then
 use them in your programs. But don't force others to.
 Let it be freedom of choice. I, personally, think that
 small ifs without {}s look neater: (snip)


It's not about how things look; it's about adding the line:


     if (health <= 0)
         Die();
     else


          printf("Some debugging information to explain why the Sound() call
isn't working god damn it\n" );          


         Sound(painsound);


...at 1 in the morning...

...on Sunday night...

...before the beta deadline on Monday...

...after 5 weeks of crunch time...

...while listening to a junior programmer who shares your 
office trying to explain _his_ bug to you...

...and trying to ignore the head of product development 
asking you how that sound bug's coming along.

Sure, only an idiot would forget to add the braces when 
adding another statement to an else clause. Under those 
and similar conditions, however, I'm an idiot.

-RB
Nov 20 2001
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Russell Borogove" <kaleja estarcion.com> wrote in message
news:3BFAA487.65459F63 estarcion.com...


 Sure, only an idiot would forget to add the braces when
 adding another statement to an else clause. Under those
 and similar conditions, however, I'm an idiot.


First, you aren't =) So there must be something wrong
with the conditions.

Second, what's the problem anyhow? Just consider always
putting {}'s around blocks in _your_ programs a rule.
There is no need for compiler to enforce this.
Nov 20 2001
parent Russell Borogove <kaleja estarcion.com> writes:
Pavel Minayev wrote:

 
 "Russell Borogove" <kaleja estarcion.com> wrote in message
 news:3BFAA487.65459F63 estarcion.com...
 

 Sure, only an idiot would forget to add the braces when
 adding another statement to an else clause. Under those
 and similar conditions, however, I'm an idiot.


 
 First, you aren't =) So there must be something wrong
 with the conditions.


Yes, definitely, there's something wrong with the conditions...


 Second, what's the problem anyhow? Just consider always
 putting {}'s around blocks in _your_ programs a rule.
 There is no need for compiler to enforce this.


Yes; the fact that some of my coworkers don't {} consistently
is another thing wrong with the conditions here, not a 
problem with C per se.

-RB
Nov 20 2001
prev sibling parent reply "Roberto Mariottini" <rmariottini lycosmail.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in
news:9tbd08$205u$1 digitaldaemon.com...

 The C way of defining a block - {} - is supposed to be used freely.
 Look, if you force the {}'s, then what's the first brace is used for?
 Since every if() defines a new block by your proposal, the brace
 is just useless since it tells compiler of something that it's already
 aware of. As such, it's a waste of time and space. On other hand,
 the ending } looks quite ugly alone, so you have to replace it by
 something else, like PHP alternative syntax:

     if (condition):
         statements
     endif;


<irony on>

Looking by this side, in the 'if' above what's the first parenthesis is used
for?
Since every 'if' defines a condition the parenthesis is just useless since
it tells
compiler of something that it's already aware of. As such, it's a waste of
time
and space. Look:

   if condition)
       statement

On other hand  the ending ) looks quite ugly alone, so you have to replace
it by
something else, like 'then':

  if condition then
      statement

<irony off>

I disagree with this.
Forcing braces means clearer code, and looks nicer, as already has been done
for
conditions in C.

Ciao.
Nov 22 2001
parent reply "Pavel Minayev" <evilone omen.ru> writes:
 Looking by this side, in the 'if' above what's the first parenthesis is


used

 for?
 Since every 'if' defines a condition the parenthesis is just useless since
 it tells
 compiler of something that it's already aware of. As such, it's a waste of
 time
 and space.


Absolutely! =|


 I disagree with this.
 Forcing braces means clearer code, and looks nicer, as already has been


done

 for
 conditions in C.


The problem with if (and other constructs as well) is that it could
be hard to separate the condition from the statement for the parser:

    if a ++b;

So there _must_ be a delimiter. Only one. However, two C braces
are just two chars, while Pascal's single "then" is four. So C
rules here! And there is no way to "un-force" braces for conditions...

Blocks, on other hand, are different thing. There is a clear indicator
of the end of statement - semicolon, so there is no ambiguity to
resolve. And I must claim that _properly_ written code without braces
around blocks may, in fact, be more readable than something with them:

    if (condition)
        dosomething();
    else
        dosomethingelse();

    - vs -

    if (condition) { dosomething();
    } else { dosomethingelse();
    }

BTW this is what I actually saw today in one of my friend's code!
Quite interesting way to format code, don't you think?

And yes, he always puts braces... =)
Nov 22 2001
parent reply Aaron <arh14 cornell.edu> writes:
Pavel Minayev wrote:


 The problem with if (and other constructs as well) is that it could
 be hard to separate the condition from the statement for the parser:
 
     if a ++b;
 
 So there _must_ be a delimiter. Only one. However, two C braces
 are just two chars, while Pascal's single "then" is four. So C
 rules here! And there is no way to "un-force" braces for conditions...


But Pavel, you *yourself* said this in
news://news.digitalmars.com/9tbd08%24205u%241%40digitaldaemon.com!:

| On other hand,
| the ending } looks quite ugly alone, so you have to replace it by
| something else, like PHP alternative syntax:
|
|   if (condition):
|        statements
|   endif;

so isn't a colon and the text "endif;" a lot more to type than two
measly braces?  : and endif; is a lot more to type, less symmetric and
just extra grammar to keep in one's head.  And for the record, I didn't
suggest mandating braces around everything.  In some cases you really
*don't* have a conceptual block.  I regularly write code like this:

if (condition) something;
else if (condition2) somethingelse;
else someotherthing;

If these one liners are particularly verbose, I might add braces just
for clarity:

if (condition) {
  something;
} else if (condition2) {
  somethingelse;
} else {
  someotherthing;
}

So in these situations not mandating braces may be good.  But in a try {
} catch () {} block, you *really* do have a conceptual block - the code
you want to "contain", even if it is a one liner.  In this case, I don't
see where clarity can be gained by saving 2-4 brace characters. 
Especially in cases of complex statements like loops, as has been
mentioned before in this thread.

Aaron

(if there are C syntax errors in the code I post, forgive me, I'm a Java
programmer, which btw should not be considered a liability if one is
inclined to think so, when talking about syntax of new features like try
{} catch () {})
Dec 21 2001
next sibling parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Aaron" <arh14 cornell.edu> wrote in message
news:3C236636.B31136D0 cornell.edu...


 So there _must_ be a delimiter. Only one. However, two C braces
 are just two chars, while Pascal's single "then" is four. So C
 rules here! And there is no way to "un-force" braces for conditions...


 But Pavel, you *yourself* said this in
 news://news.digitalmars.com/9tbd08%24205u%241%40digitaldaemon.com!:

 | On other hand,
 | the ending } looks quite ugly alone, so you have to replace it by
 | something else, like PHP alternative syntax:
 |
 |   if (condition):
 |        statements
 |   endif;

 so isn't a colon and the text "endif;" a lot more to type than two
 measly braces?  : and endif; is a lot more to type, less symmetric and
 just extra grammar to keep in one's head.  And for the record, I didn't


I said that it has to be done that way. I didn't say I like it
(but why shouldn't I? I still like BASIC which has similar syntax).


 suggest mandating braces around everything.  In some cases you really
 *don't* have a conceptual block.  I regularly write code like this:

 if (condition) something;
 else if (condition2) somethingelse;
 else someotherthing;

 If these one liners are particularly verbose, I might add braces just
 for clarity:

 if (condition) {
   something;
 } else if (condition2) {
   somethingelse;
 } else {
   someotherthing;
 }


My point here is that I almost _always_ put braces on separate
lines, so my code would look:

    if (condition)
    {
        something;
    }
    else if (condition2)
    {
        somethingelse;
    }


 So in these situations not mandating braces may be good.  But in a try {
 } catch () {} block, you *really* do have a conceptual block - the code
 you want to "contain", even if it is a one liner.  In this case, I don't
 see where clarity can be gained by saving 2-4 brace characters.
 Especially in cases of complex statements like loops, as has been
 mentioned before in this thread.


I've already mentioned of my style and I use it with loops as well,
and try-blocks... so it really adds size to my program, visually
at least. Anyhow, I still don't see any problem: if you think that
{}'s are better, always put them in your program. My style absolutely
different: when I have a single statement, I _never_ put braces -
with a few exceptions that aren't worth mentioning. With proper
indentation, it doesn't really matters - both are easily understood:

    // my style            // your style
    try                    try {
        something;            something
    finally                } finally {
        dosomething;            dosomething;
                           }

So far I don't see any reason for =requiring= blocks. Let users choose
the preferred way themselves.

BTW so far I must say that I was really pleased when I saw that
D doesn't require blocks in try..catch..finally. Thank you very
much, Walter! =)
Dec 21 2001
parent "Walter" <walter digitalmars.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:9vvrtg$1g3d$1 digitaldaemon.com...

 BTW so far I must say that I was really pleased when I saw that
 D doesn't require blocks in try..catch..finally. Thank you very
 much, Walter! =)


Uh-oh, I think you found a bug!
Dec 21 2001
prev sibling parent reply "Roberto Mariottini" <rmariottini lycosmail.com> writes:
"Aaron" <arh14 cornell.edu> wrote in message
news:3C236636.B31136D0 cornell.edu...

 Pavel Minayev wrote:


 The problem with if (and other constructs as well) is that it could
 be hard to separate the condition from the statement for the parser:

     if a ++b;

 So there _must_ be a delimiter. Only one. However, two C braces
 are just two chars, while Pascal's single "then" is four. So C
 rules here! And there is no way to "un-force" braces for conditions...


 But Pavel, you *yourself* said this in
 news://news.digitalmars.com/9tbd08%24205u%241%40digitaldaemon.com!:

 | On other hand,
 | the ending } looks quite ugly alone, so you have to replace it by
 | something else, like PHP alternative syntax:
 |
 |   if (condition):
 |        statements
 |   endif;

 so isn't a colon and the text "endif;" a lot more to type than two
 measly braces?  : and endif; is a lot more to type, less symmetric and
 just extra grammar to keep in one's head.


I thought this:
Is the () really needed? Answer: no.
You can write:

  if condition
  {
       statements
  }

This is simmetric and it saves two strokes. Since braces are required there
is no more need
for a condition delimiter (there already are the keyword 'if' and the open
brace '{').
If you want you can keep parenthesis for clarity: '(condition)' is the same
as 'condition'.

I'm strongly for mandatory blocks.

Ciao
Jan 07 2002
next sibling parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Roberto Mariottini" <rmariottini lycosmail.com> wrote in message
news:a1c5sn$11ms$1 digitaldaemon.com...


 I thought this:
 Is the () really needed? Answer: no.
 You can write:

   if condition
   {
        statements
   }

 This is simmetric and it saves two strokes. Since braces are required


there

 is no more need
 for a condition delimiter (there already are the keyword 'if' and the open
 brace '{').
 If you want you can keep parenthesis for clarity: '(condition)' is the


same

 as 'condition'.

 I'm strongly for mandatory blocks.


You're right here... but it seems to me it's a bit too late. There is
a compiler already, there is some code for it, like Phobos - not many
yet, but still... so the conventions will most likely remain the same.

...and I like it! =)
Jan 07 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
I've also noticed that Walter himself uses blockless if quite
often - so I guess you won't get what you want anyhow ;)
Jan 07 2002
parent "Roberto Mariottini" <rmariottini lycosmail.com> writes:
"Pavel Minayev" <evilone omen.ru> ha scritto nel messaggio
news:a1c76o$12m0$1 digitaldaemon.com...

 I've also noticed that Walter himself uses blockless if quite
 often - so I guess you won't get what you want anyhow ;)


Ok, let's face it.
Walter, can I have front-end sources available, in the future, to modify it
to
suit my needs?

Ciao.
Jan 07 2002
prev sibling next sibling parent "Sean L. Palmer" <spalmer iname.com> writes:
How about:

parenthesis around if or while control expressions could be optional ONLY IF
the body is a block.  If a statement is encountered without first
encountering an open brace, and there weren't parens around the expression,
it's a syntax error.  That way it's legal to do it either way so long as you
follow the rules.  The compiler should be able to catch most errors pretty
soon if they forget and do something like this, which should be illegal
since blocks aren't mandatory:

if x == 5
  DoSomething();   // error: found statement not block, but no parens found
for if control clause

Yet either of these would be valid:

if x == 5
{
  DoSomething();
}

if (x == 5)
  DoSomething();

Dunno, Walter may think it is too ambiguous.  FWIW I'm all for mandatory
blocks too.  I'd rather type blocks than parenthesis.

Sean


 I thought this:
 Is the () really needed? Answer: no.
 You can write:

   if condition
   {
        statements
   }

 This is simmetric and it saves two strokes. Since braces are required


there

 is no more need
 for a condition delimiter (there already are the keyword 'if' and the open
 brace '{').
 If you want you can keep parenthesis for clarity: '(condition)' is the


same

 as 'condition'.

 I'm strongly for mandatory blocks.

 Ciao
Jan 08 2002
prev sibling parent reply Aaron <arh14 cornell.edu> writes:
Ugh...I'd have to say I prefer the parens simply for uniformity.  I
don't see any reason to introduce such nonconformity just to save 2
characters.  Everybody coming from C, C++ and Java (not to mention many
many other languages that adopt C-like syntax) knows intuitively that
conditions are wrapped by parans, and it makes them easy to spot. 
Optional syntax just adds confusion (ok, maybe Pavel has a case with his
particular style, as long as he can ensure nobody else working on his
code unwittingly adds lines to undelimited blocks and adopts his
indenting to keep everythign clear).

I'd mandate parans around loop conditions for the aforementioned clarity
and intuitiveness, and allow optional blocks in try/catch for the Pavels
around (blocks are already optional in most/every other construct),
although I always use braces with them myself.

Aaron

Roberto Mariottini wrote:

 


[snip]

 
 I thought this:
 Is the () really needed? Answer: no.
 You can write:
 
   if condition
   {
        statements
   }
 
 This is simmetric and it saves two strokes. Since braces are required there
 is no more need
 for a condition delimiter (there already are the keyword 'if' and the open
 brace '{').
 If you want you can keep parenthesis for clarity: '(condition)' is the same
 as 'condition'.
 
 I'm strongly for mandatory blocks.
 
 Ciao
Jan 11 2002
next sibling parent "Pavel Minayev" <evilone omen.ru> writes:
"Aaron" <arh14 cornell.edu> wrote in message
news:3C3EF160.83AE13E3 cornell.edu...


 I'd mandate parans around loop conditions for the aforementioned clarity
 and intuitiveness, and allow optional blocks in try/catch for the Pavels
 around (blocks are already optional in most/every other construct),
 although I always use braces with them myself.


Yeeeeeeeeeaaaaaaah! =)
Jan 11 2002
prev sibling parent "Roberto Mariottini" <rmariottini lycosmail.com> writes:
"Aaron" <arh14 cornell.edu> ha scritto nel messaggio
news:3C3EF160.83AE13E3 cornell.edu...

[...]
 I'd mandate parans around loop conditions for the aforementioned clarity
 and intuitiveness, and allow optional blocks in try/catch for the Pavels
 around (blocks are already optional in most/every other construct),
 although I always use braces with them myself.


I'd mandate braces for the aforementioned clarity and intuitiveness,
although I always use parans around loop conditions with them myself.

:-)

Ciao
Jan 14 2002