Semicolons: mostly unnecessary?

[Pelle Månsson]

KennyTM~ wrote:
> On Oct 22, 09 21:17, Pelle Månsson wrote:
>> 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.
> 
> By whitespace I mean spaces (U+0020), tabs (U+0009), newlines (U+000A) 
> and other space characters (U+000B, U+000C, U+000D).
You can obviously not have newlines as whitespace and remove semicolon. 
That would, as you have demonstrated, not work. I think we all knew that.