www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - CaseStatement specification issue

reply "Sergey Kozyr" <s.trump gmail.com> writes:
I was reading D language reference and found some issue with 
"case ... :" statement specifications.
Documentation http://dlang.org/statement#CaseStatement  says that 
after

case 1:

must be non-empty statement "ScopeStatementList". For example

case 1:

}
case 2: ;
case 3
Aug 14 2014
next sibling parent reply "Sergey Kozyr" <s.trump gmail.com> writes:
Sorry for previous message. Once again:

I was reading D language reference and found some issue with
"case ... :" statement specifications.
Documentation http://dlang.org/statement#CaseStatement  says
that after

case 1:

must be non-empty statement "ScopeStatementList". For example

case 1:
   return true;

case 2: {
}

case 3: ;

But next example concerns me:

case 1:
case 2:
   return true;
case 3:
   return false;

After "case 1:" we see no statement at all. This conflicts with 
"CaseStatement" rule of documentation. But this is right D code.
I think language reference must be updated.
Aug 14 2014
next sibling parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Sergey Kozyr"  wrote in message 
news:khaugqemvygmsaaeyild forum.dlang.org...


 case 1:
 case 2:
    return true;
 case 3:
    return false;

 After "case 1:" we see no statement at all. This conflicts with 
 "CaseStatement" rule of documentation. But this is right D code.
 I think language reference must be updated.


"case 2:" is a CaseStatement and it's after "case 1:"
Aug 14 2014
prev sibling parent reply "Baz" <basile.burg gmx.com> writes:
On Thursday, 14 August 2014 at 13:19:36 UTC, Sergey Kozyr wrote:

 Sorry for previous message. Once again:

 I was reading D language reference and found some issue with
 "case ... :" statement specifications.
 Documentation http://dlang.org/statement#CaseStatement  says
 that after

 case 1:

 must be non-empty statement "ScopeStatementList". For example

 case 1:
   return true;

 case 2: {
 }

 case 3: ;

 But next example concerns me:

 case 1:
 case 2:
   return true;
 case 3:
   return false;

 After "case 1:" we see no statement at all. This conflicts with 
 "CaseStatement" rule of documentation. But this is right D code.
 I think language reference must be updated.


It's a "fall trough":

https://en.wikipedia.org/wiki/Switch_statement#Fallthrough
Aug 14 2014
parent reply "AsmMan" <lol.themask gmail.com> writes:
On Thursday, 14 August 2014 at 16:01:05 UTC, Baz wrote:

 On Thursday, 14 August 2014 at 13:19:36 UTC, Sergey Kozyr wrote:

 Sorry for previous message. Once again:

 I was reading D language reference and found some issue with
 "case ... :" statement specifications.
 Documentation http://dlang.org/statement#CaseStatement  says
 that after

 case 1:

 must be non-empty statement "ScopeStatementList". For example

 case 1:
  return true;

 case 2: {
 }

 case 3: ;

 But next example concerns me:

 case 1:
 case 2:
  return true;
 case 3:
  return false;

 After "case 1:" we see no statement at all. This conflicts 
 with "CaseStatement" rule of documentation. But this is right 
 D code.
 I think language reference must be updated.


 It's a "fall trough":

 https://en.wikipedia.org/wiki/Switch_statement#Fallthrough


It's a fall trough but it is not the reason why it does works. It 
does because (as Daniel already mentioned) a case is a valid 
statement, therefore a case following other case is a totally 
valid statement.

for example:

case 1:
case 2:
   return true;

There are three statements. One which must be followed by another 
(case keyword) and another by an expression (return keyword).

It is not even a special-case in the switch in C language. The 
switch keyword accept a expression constant as argument and must 
be followed by a statement, so:

switch(1) return 0;

is valid C code and no standard-compliant compiler must give an 
error about that. The fact we can do:

switch(E)
{
    case 1: ... break;
    case 2: .... break;
default: ... break;
}

That's why compound-statement is a statement too (which switch 
does accept same reason why break keyword is needed)
Aug 14 2014
next sibling parent "Baz" <basile.burg gmx.com> writes:
On Thursday, 14 August 2014 at 17:10:50 UTC, AsmMan wrote:

 On Thursday, 14 August 2014 at 16:01:05 UTC, Baz wrote:

 On Thursday, 14 August 2014 at 13:19:36 UTC, Sergey Kozyr 
 wrote:

 Sorry for previous message. Once again:

 I was reading D language reference and found some issue with
 "case ... :" statement specifications.
 Documentation http://dlang.org/statement#CaseStatement  says
 that after

 case 1:

 must be non-empty statement "ScopeStatementList". For example

 case 1:
 return true;

 case 2: {
 }

 case 3: ;

 But next example concerns me:

 case 1:
 case 2:
 return true;
 case 3:
 return false;

 After "case 1:" we see no statement at all. This conflicts 
 with "CaseStatement" rule of documentation. But this is right 
 D code.
 I think language reference must be updated.


 It's a "fall trough":

 https://en.wikipedia.org/wiki/Switch_statement#Fallthrough


 It's a fall trough but it is not the reason why it does works. 
 It does because (as Daniel already mentioned) a case is a valid 
 statement, therefore a case following other case is a totally 
 valid statement.

 for example:

 case 1:
 case 2:
   return true;

 There are three statements. One which must be followed by 
 another (case keyword) and another by an expression (return 
 keyword).

 It is not even a special-case in the switch in C language. The 
 switch keyword accept a expression constant as argument and 
 must be followed by a statement, so:

 switch(1) return 0;

 is valid C code and no standard-compliant compiler must give an 
 error about that. The fact we can do:

 switch(E)
 {
    case 1: ... break;
    case 2: .... break;
 default: ... break;
 }

 That's why compound-statement is a statement too (which switch 
 does accept same reason why break keyword is needed)


I totally agree. I just wanted to mention the technical name.
Aug 14 2014
prev sibling parent reply "Sergey Kozyr" <s.trump gmail.com> writes:
 It's a fall trough but it is not the reason why it does works. 
 It does because (as Daniel already mentioned) a case is a valid 
 statement, therefore a case following other case is a totally 
 valid statement.

 for example:

 case 1:
 case 2:
   return true;

 There are three statements. One which must be followed by 
 another (case keyword) and another by an expression (return 
 keyword).



I agree that this is a valid D language construction. But 
documentation says that statement "case 1:" must be followed by 
any statement except other "case" or "default".
Let's open doc http://dlang.org/statement#CaseStatement
You see that "case ArgumentList :" is followed by 
"ScopeStatementList" 
(http://dlang.org/statement#ScopeStatementList) which is a list 
of any statements except CaseStatement or CaseRangeStatement or 
DefaultStatement. This rule conflicts with actual D language 
compiler.
Aug 15 2014
parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 15 Aug 2014 19:46:07 +0000
Sergey Kozyr via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 Let's open doc http://dlang.org/statement#CaseStatement


and we'll find some more bugs there:

  CaseStatement:
    case ArgumentList : ScopeStatementList

  ArgumentList:
    AssignExpression
    AssignExpression ,
    AssignExpression , ArgumentList

  AssignExpression:
    ConditionalExpression
    ConditionalExpression =3D AssignExpression
    ConditionalExpression +=3D AssignExpression
    ...

and so on.

so we can see that things like 'case n+=3D5:' should be allowed, while
they are not.
Aug 15 2014
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 08/16/2014 12:21 AM, ketmar via Digitalmars-d wrote:

 so we can see that things like 'case n+=5:' should be allowed, while
 they are not.


What is the problem? This passes DMD's parser.
Aug 15 2014
parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sat, 16 Aug 2014 01:31:42 +0200
Timon Gehr via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 What is the problem? This passes DMD's parser.


that is the problem: it shouldn't. this has no sense, and it's easy to
fix this in grammar itself.
Aug 15 2014
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 08/16/2014 01:41 AM, ketmar via Digitalmars-d wrote:

 On Sat, 16 Aug 2014 01:31:42 +0200
 Timon Gehr via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 What is the problem? This passes DMD's parser.


 that is the problem: it shouldn't.


That's not what you said.

On 08/16/2014 12:21 AM, ketmar via Digitalmars-d wrote:

 and we'll find some more bugs there:
 ...
 so we can see that things like 'case n+=5:' should be allowed, while
 they are not.




 this has no sense, and it's easy to
 fix this in grammar itself.


There is nothing to be 'fixed'. The code is still rejected when it is 
analysed.
Aug 15 2014
parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sat, 16 Aug 2014 02:20:27 +0200
Timon Gehr via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 What is the problem? This passes DMD's parser.


 that is the problem: it shouldn't.


 That's not what you said.


that's what i mean. ok, i should write it clear.


 There is nothing to be 'fixed'. The code is still rejected when it is=20
 analysed.


there is no sense to accept such code in parser anyway, and it can be
easily fixed in grammar.

ok, there is some sense with overloaded opAssign() and friends, but
such code is awful and i believe that there is no sane reasons to allow
such abomination.
Aug 15 2014
prev sibling next sibling parent reply "Sergey Kozyr" <s.trump gmail.com> writes:
Also two more errors in documentation:
1. One member of an anonymous enum
On page http://dlang.org/enum.html in "Manifest Constants" 
section there is an example of anonymous enum with a single 
member. But top rules on the same page don't have description of 
this case. Rules says that members are always enclosed with 
braces '{' and '}'. I think documentation must be updated.

2. Functions with "in" and "out" contracts
On function declaration page http://dlang.org/function.html there 
is mention of "in" keyword with some code block and "out" block 
with some arguments and code block. This documentation page 
doesn't describe what this "in" and "out" sections mean. It's 
impossible to understand that these blocks are called 
"contracts". I downloaded DMD sources to find test where this 
contracts are described. I this this page need a link to 
"Contracts" documentation (http://dlang.org/contracts.html).
Aug 18 2014
parent reply "Brian Schott" <briancschott gmail.com> writes:
On Monday, 18 August 2014 at 09:36:39 UTC, Sergey Kozyr wrote:

 Also two more errors in documentation:
 ...


Check the list of bugs that I've already filed here: 
https://issues.dlang.org/show_bug.cgi?id=10233. If you find one 
that hasn't been filed, file it and add "spec" to the "Keywords" 
field and "10233" to the "Blocks" field. I plan on updating or 
rewriting a lot of the language specification based on these 
issues, so any that you identify will help me make the 
specification more accurate.
Aug 18 2014
parent "Sergey Kozyr" <s.trump gmail.com> writes:
On Monday, 18 August 2014 at 17:54:07 UTC, Brian Schott wrote:

 On Monday, 18 August 2014 at 09:36:39 UTC, Sergey Kozyr wrote:

 Also two more errors in documentation:
 ...


 Check the list of bugs that I've already filed here: 
 https://issues.dlang.org/show_bug.cgi?id=10233. If you find one 
 that hasn't been filed, file it and add "spec" to the 
 "Keywords" field and "10233" to the "Blocks" field. I plan on 
 updating or rewriting a lot of the language specification based 
 on these issues, so any that you identify will help me make the 
 specification more accurate.


I've created three issues in bug tracker: 13326, 13327, 13328.
As far as I can see these issues could be fixed with pull 
requests to github repository 
https://github.com/D-Programming-Language/dlang.org . Am I right?
Aug 18 2014
prev sibling next sibling parent "Sergey Kozyr" <s.trump gmail.com> writes:
One more documentation issue. I've took sample from 
http://dlang.org/template.html


 interface Addable(T)
 {
     final R add(this R)(T t)
     {
         return cast(R)this;  // cast is necessary, but safe
     }
 }
 
 class List(T) : Addable!T
 {
     List remove(T t)
     {
         return this;
     }
 }
 
 void main()
 {
     auto list = new List!int;
     list.add(1).remove(1);  // ok
 }


I want to pay attention at line 9:

 class List(T) : Addable!T


As ClassDeclaration rule 
(http://dlang.org/class.html#ClassDeclaration) says after ':' you 
can see list of base classes. But "BaseClassList" rule allows 
only Identifier separated with comma. But here we have 
TemplateInstance instead of Identifier.
This sample code is compiled by DMD2 compiler (but interface must 
be replaced with class previously). So I think specification must 
be updated in "SuperClass" and "Interface" rules.


 SuperClass:
    Identifier
    TemplateInstance

 Interface:
    Identifier
    TemplateInstance


Do you want me to create a bug under issue 10233?
Aug 20 2014
prev sibling parent "Sergey Kozyr" <s.trump gmail.com> writes:
One more thing in specification. "AutoDeclarationX" rule 
(http://dlang.org/declaration.html#AutoDeclarationX) seems broken.


 AutoDeclarationX:
     Identifier = TemplateParameters Initializer
     AutoDeclarationX , Identifier TemplateParameters = 
 Initializer


In second line equal sign is between "Identifier" and 
"TemplateParameters". While in third line equal sign is between 
"TemplateParameters" and "Initializer". I think second line 
contains error.

Do you want me to create a bug at issues.dlang.org?
Aug 20 2014