"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