Semicolons: mostly unnecessary?

AJ aj at nospam.net
Thu Oct 22 12:08:57 PDT 2009


"Lars T. Kyllingstad" <public at kyllingen.NOSPAMnet> wrote in message 
news:hbpcjk$2cl6$1 at digitalmars.com...
> 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.
>

So much for attracting C++ users by not making D foreign to them. 





More information about the Digitalmars-d mailing list