Semicolons: mostly unnecessary?

[KennyTM~]

On Oct 22, 09 21:51, Pelle Månsson wrote:
> KennyTM~ wrote:
>> 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)
> Maybe true, but not ambigous.

Great, now how should I fix the old D syntax that concatenates over 
multiple lines?

auto s = localizeStr("This won't work because ")
        ~ localize("the unary ~ is ")           // compile error for AJ
        ~ localize("the bitwise-not operator.") // compile error for AJ

Anyway, my point is that, if you want to eliminate the semicolon, you 
have to change the D syntax and break old code. And if all you need is a 
re-syntax-ized D with optional semicolon, there is already one here. 
It's called Delight.