Semicolons: mostly unnecessary?

[Pelle Månsson]

KennyTM~ wrote:
> On Oct 22, 09 19:03, Pelle Månsson wrote:
>> KennyTM~ wrote:
>>> On Oct 22, 09 13:57, AJ wrote:
>>>> "KennyTM~"<kennytm at gmail.com> wrote in message
>>>> news:hbopns$125k$1 at digitalmars.com...
>>>>> On Oct 22, 09 12:29, AJ wrote:
>>>>>> "Adam D. Ruppe"<destructionator at gmail.com> wrote in message
>>>>>> news:mailman.228.1256181155.20261.digitalmars-d at 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);.
>>>
>>> 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 clearly means the global int a is set to one, and the local t has
>> type S.
> 
> No, s(lots of whitespace).a is a valid expression. You shouldn't insert 
> a statement break there.
Try an editor that shows you where the line breaks are.