Tee hee. I can make the compiler swallow something silly:

module silly;

interface I{
	void foo();
}

class C: public private protected package protected public protected public private protected package I{
	void foo(){}
}

void main(){}

Hello Ellery,

> Tee hee. I can make the compiler swallow something silly:
> 
> module silly;
> 
> interface I{
> void foo();
> }
> class C: public private protected package protected public protected
> public private protected package I{
> void foo(){}
> }
> void main(){}
> 

Um. OK. It turns out it's easier to make the compiler eat that than it is to make it reject it. Also sometimes it's handy to have it look at only the last cases (I think that's what it does). As an example, in generated code. Another example of this is in unix command line apps that often have on/off flag pairs that can be mixed ad-nauseum because they grab flags from several different sources that need to override each other.

Ellery Newcomer wrote:
> Tee hee. I can make the compiler swallow something silly:
> 
> module silly;
> 
> interface I{
>     void foo();
> }
> 
> class C: public private protected package protected public protected public private protected package I{
>     void foo(){}
> }
> 
> void main(){}

Also, access specifiers on inherited or implemented base types aren't honored:
class C : private I {}

C is still implicitly convertible to I.

BCS wrote:
> Hello Ellery,
> 
>> Tee hee. I can make the compiler swallow something silly:
>>
>> module silly;
>>
>> interface I{
>> void foo();
>> }
>> class C: public private protected package protected public protected
>> public private protected package I{
>> void foo(){}
>> }
>> void main(){}
>>
> 
> Um. OK. It turns out it's easier to make the compiler eat that than it is to make it reject it. Also sometimes it's handy to have it look at only the last cases (I think that's what it does). As an example, in generated code. Another example of this is in unix command line apps that often have on/off flag pairs that can be mixed ad-nauseum because they grab flags from several different sources that need to override each other.
> 
> 

I don't buy that. Not that I'm a C guru or anything, but it looks to me that Parser::BaseClasses could be easily edited to make the point in question go away.
Also, I don't quite follow your rationale, but I'll accept it just the same. I like this feature :D

Reply to Ellery,

> I don't buy that. Not that I'm a C guru or anything, but it looks to
> me that Parser::BaseClasses could be easily edited to make the point
> in question go away.
> 

it's not a parser thing but a grammar thing. It would be complex to define a grammar that allows one each of the different types of prefixes that are allowed:

int a = 5;
auto b = 5;
const c = 5;
static d = 5;
const static int e = 5;
protected const static int f = 5;
static const protected g = 5;

each of those is allow and reasonable in different contexts. To avoid redundant grammars and inconsistencies they are generalized and also shared with classes, structs, etc.

BCS wrote:
> Reply to Ellery,
> 
>> I don't buy that. Not that I'm a C guru or anything, but it looks to
>> me that Parser::BaseClasses could be easily edited to make the point
>> in question go away.
>>
> 
> it's not a parser thing but a grammar thing. It would be complex to define a grammar that allows one each of the different types of prefixes that are allowed:
> 
> int a = 5;
> auto b = 5;
> const c = 5;
> static d = 5;
> const static int e = 5;
> protected const static int f = 5;
> static const protected g = 5;
> 
> each of those is allow and reasonable in different contexts. To avoid redundant grammars and inconsistencies they are generalized and also shared with classes, structs, etc.
> 
> 

I don't buy that either. The subject was access specifiers for base classes, not storage classes for declarations or access specifiers for statements. In those cases I would grant your point, but a base class has precisely one access specifier and no storage classes. It would not be complex to define such a grammar and in fact the D grammar does precisely this.

Reply to Ellery,

> BCS wrote:
> 
>> Reply to Ellery,
>> 
>>> I don't buy that. Not that I'm a C guru or anything, but it looks to
>>> me that Parser::BaseClasses could be easily edited to make the point
>>> in question go away.
>>> 
>> it's not a parser thing but a grammar thing. It would be complex to
>> define a grammar that allows one each of the different types of
>> prefixes that are allowed:
>> 
>> int a = 5;
>> auto b = 5;
>> const c = 5;
>> static d = 5;
>> const static int e = 5;
>> protected const static int f = 5;
>> static const protected g = 5;
>> each of those is allow and reasonable in different contexts. To avoid
>> redundant grammars and inconsistencies they are generalized and also
>> shared with classes, structs, etc.
>> 
> I don't buy that either. The subject was access specifiers for base
> classes, not storage classes for declarations or access specifiers for
> statements. In those cases I would grant your point, but a base class
> has precisely one access specifier and no storage classes. It would
> not be complex to define such a grammar and in fact the D grammar does
> precisely this.
> 

OTOH it /would/ be redundant because you would then need to define access specifiers independently for class declarations as well as for variable declarations. IIRC, as things stand now the access specifiers are consumed by the grammar before it even gets from the generic declarations grammar to the class/struct/variable specialization.

Declaration ::= DeclAnnotation Item
Item ::= ClassDecl | StructDecl | VarDecl | ...

Reply to Ellery,

> I don't buy that either. The subject was access specifiers for base
> classes, not storage classes for declarations or access specifiers for
> statements. In those cases I would grant your point, but a base class
> has precisely one access specifier and no storage classes. It would
> not be complex to define such a grammar and in fact the D grammar does
> precisely this.
> 

another reason: to avoid this requiters more look ahead