Semicolons: mostly unnecessary?

Lars T. Kyllingstad public at kyllingen.NOSPAMnet
Thu Oct 22 03:36:39 PDT 2009


AJ wrote:
> "KennyTM~" <kennytm at gmail.com> wrote in message 
> news:hbpa89$27si$1 at digitalmars.com...
>> 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);.
> 
> I don't think it should.
> 
>> 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's not ambiguous, it's erroneous. The passage means:
> 
> auto t = s // fine
> .a = 1 // can't have .a without something on the left of the dot
>     // or else remove the dot


In D you use the dot like that to access globals, cf. the comment in 
KennyTM~s example.

-Lars



More information about the Digitalmars-d mailing list