Jump to page: 1 2
Thread overview
CaseStatement specification issue
Aug 14, 2014
Sergey Kozyr
Aug 14, 2014
Sergey Kozyr
Aug 14, 2014
Daniel Murphy
Aug 14, 2014
Baz
Aug 14, 2014
AsmMan
Aug 14, 2014
Baz
Aug 15, 2014
Sergey Kozyr
Aug 15, 2014
ketmar
Aug 15, 2014
Timon Gehr
Aug 15, 2014
ketmar
Aug 16, 2014
Timon Gehr
Aug 16, 2014
ketmar
Aug 18, 2014
Sergey Kozyr
Aug 18, 2014
Brian Schott
Aug 18, 2014
Sergey Kozyr
Aug 20, 2014
Sergey Kozyr
Aug 20, 2014
Sergey Kozyr
August 14, 2014
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
August 14, 2014
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.
August 14, 2014
"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:" 

August 14, 2014
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

August 14, 2014
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)

August 14, 2014
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.

August 15, 2014
> 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.
August 15, 2014
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 = AssignExpression
    ConditionalExpression += AssignExpression
    ...

and so on.

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


August 15, 2014
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.
August 15, 2014
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.


« First   ‹ Prev
1 2