AJ wrote:
"KennyTM~" <kenn...@gmail.com> wrote in message news:hbpa89$27s...@digitalmars.com...
On Oct 22, 09 13:57, AJ wrote:
"KennyTM~"<kenn...@gmail.com>  wrote in message
news:hbopns$125...@digitalmars.com...
On Oct 22, 09 12:29, AJ wrote:
"Adam D. Ruppe"<destructiona...@gmail.com>   wrote in message
news:mailman.228.1256181155.20261.digitalmar...@puremagic.com...
On Wed, Oct 21, 2009 at 09:25:34PM -0500, AJ wrote:
That's not D source code. Why do you keep trying to use English text as
an
example?
The logic behind all the arguments you make,
That would be "all fine and dandy", but I'm not arguing about anything.
(So
you must be arguing? About what?).

except for one, should apply
equally well to English as it does to D.
That's silly. There is no need to use the text of Shakespeare's tragedies
to
allude to source code. There is no need and it is entirely inappropriate
to
expand the context of the issue to other realms. The context is
(currently):
semicolons as statement terminators for single-statement lines.

Cons:

1. Makes source code less comprehensible.

Based on what? Because you say so?
It's more to digest when it's not necessary. It's easier to identify
something when it's in less intricate (read, plain) surroundings.

<snipped inappropriate context reference>


2. Is redundant with the newline designator.

<snipped inappropriate context reference>

is obviously false,
If I put it on the list, it wasn't obvious at all, even if it is
incorrect
(though I think it is correct).

unless
you specifically require a line continuation character:

a = b +
c
Without semicolon requirement:

a=b+ // this is an error
c // this is OK

With semicolon requirement:

a=b+; // this is an error
c; // this is OK

What's the diff?

A newline and a semicolon are not redundant unless you specifically
define
a statement as being one and only one line.
A semicolon is redundate with newline for single-statement lines. Oh, you say that a lot of constructs are inherently single statements but written
on
multiple lines? Well, that may be just the kind of examination I was
looking
for (ironic that _I_ had to bring it up, huh):

if(true)
      dothis()

That situation has to be evaluated: is parsing at the construct level too
much effort or is it desireable? (ParseIfStatement()). Statement-level
parsing better/worse than line-level parsing?

Back to the magic of above though. What if you rewrote it:
a = b
     +c
Without semicolon requirement:

a=b // OK
   +c // error

With semicolon requirement:

a=b; // OK
   +c; // error

What's the diff?
a=b
   +c(d)  // no error
Why not?
Good question. Because the compiler accepts a=b;+c(d);.

I don't think it should.

Whether c is declared as a variable or a function, it still looks
wrong to me. A statement can't begin with a +.
OK.

struct S { int a }
int a

void main () {
  S s
  auto t = s
  .a = 1       // ambiguity: Note that .sth means global scope.
}

That's not ambiguous, it's erroneous. The passage means:

auto t = s // fine
.a = 1 // can't have .a without something on the left of the dot
    // or else remove the dot


In D you use the dot like that to access globals, cf. the comment in KennyTM~s example.

-Lars

Reply via email to