Semicolons: mostly unnecessary?

[KennyTM~]

On Oct 22, 09 21:36, Pelle Månsson wrote:
> KennyTM~ wrote:
>> On Oct 22, 09 21:12, Ary Borenszweig 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.
>>>
>>> But without semicolons the line break becomes the new semicolon. That's
>>> what most people here don't understand. There's no ambiguity: if you
>>> have a line break and a semicolon would have been good in that place,
>>> then that line break becomes the semicolon.
>>
>> So
>>
>> auto t = s.
>> a = 1
>>
>> would now become a syntax error?
> Yes. Do you use this particular style of coding often?

auto s = "No, but you've just broken " ~
          "some other perfectly working " ~
          "D codes."
writeln(s)