Semicolons: mostly unnecessary?

KennyTM~ kennytm at gmail.com
Thu Oct 22 06:21:26 PDT 2009


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?



More information about the Digitalmars-d mailing list