www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Multiple attribute specifiers

reply Ary Manzana <asterite gmail.com> writes:
If I write this inside a module:

--------------------------------------
public private int x;
--------------------------------------

it compiles perfectly.

What is the protection level of x? public or private? Well, you can try 
compiling it and using it to find out, but I think the compiler should 
issue a warning or, much better, an error.

This confusion also appears if I write

--------------------------------------
public {

	private {

		int x;

	}

}
--------------------------------------

Again, the same question. Is x public or private?

I was going to post this to the digitalmars.D.bugs list, but I want some 
comments on this before proceeding.

I know no one would want to write such a thing, but on the compiler side 
(or other tools) it is crucial to know what should be the semantic 
(because currently it's legal).

Thanks,
Ary
Sep 06 2006
next sibling parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Comments imbeded.

Ary Manzana wrote:
 If I write this inside a module:
 
 --------------------------------------
 public private int x;
 --------------------------------------
 
 it compiles perfectly.

Okay this is odd, indeed. I would expect an error from contradictory attributes applied directly to a single decleration. I consider this a bug, personally.
 
 What is the protection level of x? public or private? Well, you can try 
 compiling it and using it to find out, but I think the compiler should 
 issue a warning or, much better, an error.
 
 This confusion also appears if I write
 
 --------------------------------------
 public {
 
     private {
 
         int x;
 
     }
 
 }
 --------------------------------------
 
 Again, the same question. Is x public or private?

In this case I would actually expect x to be private. With nested attribute blocks, my assumption is that the inner-most attributes take precedance. There may be corner-case uses for this behavior... perhaps in a property definition, a la: # class Foo { # public { # ... ... # int bar () { ... } # int bar (int x) { ... } # private int _bar ; # ... ... # } # ... ... # } Still seems needless, but I guess it ought to be allowed, but only in terms of attribute blocks. Definitely not in the first case.
 I was going to post this to the digitalmars.D.bugs list, but I want some 
 comments on this before proceeding.
 
 I know no one would want to write such a thing, but on the compiler side 
 (or other tools) it is crucial to know what should be the semantic 
 (because currently it's legal).
 
 Thanks,
 Ary

-- Chris Nicholson-Sauls
Sep 06 2006
parent Steve Horne <stephenwantshornenospam100 aol.com> writes:
On Wed, 06 Sep 2006 13:53:05 -0500, Chris Nicholson-Sauls
<ibisbasenji gmail.com> wrote:

Comments imbeded.

Ary Manzana wrote:
 If I write this inside a module:
 
 --------------------------------------
 public private int x;
 --------------------------------------
 
 it compiles perfectly.

Okay this is odd, indeed. I would expect an error from contradictory attributes applied directly to a single decleration. I consider this a bug, personally.

I'd guess it falls out of allowing several access modifier styles... class xxx { public: private int x; } This makes sense. The C++-like colon can be seen as changing a default that runs on until the next access modifier. The Java-like variant is more convenient for a this-declaration-only access modifier. With the block version supported as well, it's obviously mainly about keeping C++ and Java programmers happy, but there is a logic to layering access modifiers. In the compiler, it's probably easier to handle that as 'the last modifier is the real one' than to sort out different cases, and have more specific rules. Also, the grammar probably just allows modifiers to be added to declarations arbitrarily. Should 'private' go before or after 'static'? Why not allow both cases. But the easiest way to allow both cases will also allow two access modifiers, or two storage modifiers. After all, the following compiles fine too... static static int m_Var; No contradiction in that, of course, but still pretty wierd. The question is... is this really a problem? -- Remove 'wants' and 'nospam' from e-mail.
Sep 06 2006
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Ary Manzana wrote:
 If I write this inside a module:
 
 --------------------------------------
 public private int x;
 --------------------------------------
 
 it compiles perfectly.
 
 What is the protection level of x? public or private? Well, you can try 
 compiling it and using it to find out, but I think the compiler should 
 issue a warning or, much better, an error.

It should _definitely_ issue an error. I call this a bug indeed.
 This confusion also appears if I write
 
 --------------------------------------
 public {
 
     private {
 
         int x;
 
     }
 
 }
 --------------------------------------
 
 Again, the same question. Is x public or private?

When one protection attribute appears within an attribute block that specifies another, the inner one overrides.
 I was going to post this to the digitalmars.D.bugs list, but I want some 
 comments on this before proceeding.

The .bugs 'group contains a lot more than issues that people are _certain_ are bugs. Indeed, it's quite a good place to discuss behaviour that looks like a bug.
 I know no one would want to write such a thing, but on the compiler side 
 (or other tools) it is crucial to know what should be the semantic 
 (because currently it's legal).

By "legal", I take it you mean the compiler accepts it. By "the semantic", do you mean what the compiler does with it? Stewart. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d- s:- C++ a->--- UB P+ L E W++ N+++ o K- w++ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y ------END GEEK CODE BLOCK------ My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Sep 06 2006
parent reply Ary Manzana <asterite gmail.com> writes:
Stewart Gordon wrote:
 Ary Manzana wrote:
 If I write this inside a module:

 --------------------------------------
 public private int x;
 --------------------------------------

 it compiles perfectly.

 What is the protection level of x? public or private? Well, you can 
 try compiling it and using it to find out, but I think the compiler 
 should issue a warning or, much better, an error.

It should _definitely_ issue an error. I call this a bug indeed.

In some post of the "learn" list someone said the last attribute should be taken. I think this is ok, but it should be better to issue an error (or at least a warning) because it's pretty ugly or counter-intuitive.
 
 This confusion also appears if I write

 --------------------------------------
 public {

     private {

         int x;

     }

 }
 --------------------------------------

 Again, the same question. Is x public or private?

When one protection attribute appears within an attribute block that specifies another, the inner one overrides.
 I was going to post this to the digitalmars.D.bugs list, but I want 
 some comments on this before proceeding.

The .bugs 'group contains a lot more than issues that people are _certain_ are bugs. Indeed, it's quite a good place to discuss behaviour that looks like a bug.
 I know no one would want to write such a thing, but on the compiler 
 side (or other tools) it is crucial to know what should be the 
 semantic (because currently it's legal).

By "legal", I take it you mean the compiler accepts it. By "the semantic", do you mean what the compiler does with it?

I mean that if I want to implement a compiler, or, say, a plugin for Eclipse, I need to know this things and not just make guesses or see how the compiler works. At least it should be in the specifications.
 
 Stewart.
 

Ary
Sep 07 2006
next sibling parent Steve Horne <stephenwantshornenospam100 aol.com> writes:
On Thu, 07 Sep 2006 09:25:15 -0300, Ary Manzana <asterite gmail.com>
wrote:

Stewart Gordon wrote:

 It should _definitely_ issue an error.  I call this a bug indeed.

In some post of the "learn" list someone said the last attribute should be taken.

If your referring to me, that's not 'should be' exactly. First, I'm just a newb making noise, so don't necessarily pay too much attention. I was just saying how I interpreted the behaviour, and what the apparent plus side might be. Second, there seems to be three different ways to apply a modifier. 1. The C++-style colon syntax. 2. The multi-definition block with braces. 3. The single line definition. On principle, writing two access modifiers in the same style should generate a warning (same modifier given twice) or an error (modifiers conflict). But one form overriding another (or nesting the block form) probably not. Basically, don't allow... public private blah; or... private public { blah; } I just don't think this is such a big deal. There are other errors that D can't catch. There are errors D never will be able to catch. This one, sure, in an ideal world it should. But is it really an error that people will make? And even if they do, how much trouble will it really cause? But then again, appearances can be important too, I suppose. -- Remove 'wants' and 'nospam' from e-mail.
Sep 07 2006
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Ary Manzana wrote:
 Stewart Gordon wrote:
 Ary Manzana wrote:
 If I write this inside a module:

 --------------------------------------
 public private int x;



 It should _definitely_ issue an error.  I call this a bug indeed.

In some post of the "learn" list someone said the last attribute should be taken. I think this is ok, but it should be better to issue an error (or at least a warning) because it's pretty ugly or counter-intuitive.

Can you remember anything at all about this post? Such as who wrote it, or enough words from the subject line or body that there is some hope of finding it? <snip>
 By "legal", I take it you mean the compiler accepts it.  By "the 
 semantic", do you mean what the compiler does with it?

I mean that if I want to implement a compiler, or, say, a plugin for Eclipse, I need to know this things and not just make guesses or see how the compiler works. At least it should be in the specifications.

Because it makes absolutely no sense, and because the spec gives no resolution for it, I consider this to mean that it is illegal. On this basis, it's a bug that the compiler accepts it. So the answer for what to do if you want to implement a compiler is: Implement one that doesn't have this bug! Stewart. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d- s:- C++ a->--- UB P+ L E W++ N+++ o K- w++ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y ------END GEEK CODE BLOCK------ My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Sep 07 2006
next sibling parent Steve Horne <stephenwantshornenospam100 aol.com> writes:
On Thu, 07 Sep 2006 19:31:01 +0100, Stewart Gordon
<smjg_1998 yahoo.com> wrote:

Can you remember anything at all about this post?  Such as who wrote it, 
or enough words from the subject line or body that there is some hope of 
finding it?

I'm pretty sure he means me, so I'll just repost this with the crossposting... : First, I'm just a newb making noise, so don't necessarily pay too much : attention. I was just saying how I interpreted the behaviour, and what : the apparent plus side might be. : : : Second, there seems to be three different ways to apply a modifier. : : 1. The C++-style colon syntax. : 2. The multi-definition block with braces. : 3. The single line definition. : : On principle, writing two access modifiers in the same style should : generate a warning (same modifier given twice) or an error (modifiers : conflict). But one form overriding another (or nesting the block form) : probably not. The above referring to things like... class xxx { public: many declarations; private one_exceptional_declaration; many declarations; } : : Basically, don't allow... : : public private blah; : : or... : : private public : { : blah; : } : : I just don't think this is such a big deal. There are other errors : that D can't catch. There are errors D never will be able to catch. : This one, sure, in an ideal world it should. But is it really an error : that people will make? And even if they do, how much trouble will it : really cause? : : But then again, appearances can be important too, I suppose. -- Remove 'wants' and 'nospam' from e-mail.
Sep 07 2006
prev sibling parent reply Steve Horne <stephenwantshornenospam100 aol.com> writes:
On Thu, 07 Sep 2006 19:31:01 +0100, Stewart Gordon
<smjg_1998 yahoo.com> wrote:

Can you remember anything at all about this post?  Such as who wrote it, 
or enough words from the subject line or body that there is some hope of 
finding it?

The relevant bits from the original post, reposted and crossposted... : I'd guess it falls out of allowing several access modifier styles... : : class xxx : { : public: : private int x; : } : : This makes sense. The C++-like colon can be seen as changing a default : that runs on until the next access modifier. The Java-like variant is : more convenient for a this-declaration-only access modifier. With the : block version supported as well, it's obviously mainly about keeping : C++ and Java programmers happy, but there is a logic to layering : access modifiers. : : In the compiler, it's probably easier to handle that as 'the last : modifier is the real one' than to sort out different cases, and have : more specific rules. : : Also, the grammar probably just allows modifiers to be added to : declarations arbitrarily. Should 'private' go before or after : 'static'? Why not allow both cases. But the easiest way to allow both : cases will also allow two access modifiers, or two storage modifiers. : : After all, the following compiles fine too... : : static static int m_Var; : : No contradiction in that, of course, but still pretty wierd. : : The question is... is this really a problem? -- Remove 'wants' and 'nospam' from e-mail.
Sep 07 2006
parent Ary Manzana <asterite gmail.com> writes:
Steve Horne wrote:
 On Thu, 07 Sep 2006 19:31:01 +0100, Stewart Gordon
 <smjg_1998 yahoo.com> wrote:
 
 Can you remember anything at all about this post?  Such as who wrote it, 
 or enough words from the subject line or body that there is some hope of 
 finding it?

The relevant bits from the original post, reposted and crossposted... : I'd guess it falls out of allowing several access modifier styles... : : class xxx : { : public: : private int x; : } : : This makes sense. The C++-like colon can be seen as changing a default : that runs on until the next access modifier. The Java-like variant is : more convenient for a this-declaration-only access modifier. With the : block version supported as well, it's obviously mainly about keeping : C++ and Java programmers happy, but there is a logic to layering : access modifiers. : : In the compiler, it's probably easier to handle that as 'the last : modifier is the real one' than to sort out different cases, and have : more specific rules. : : Also, the grammar probably just allows modifiers to be added to : declarations arbitrarily. Should 'private' go before or after : 'static'? Why not allow both cases. But the easiest way to allow both : cases will also allow two access modifiers, or two storage modifiers. : : After all, the following compiles fine too... : : static static int m_Var; : : No contradiction in that, of course, but still pretty wierd. : : The question is... is this really a problem?

I finally think it's not a big deal, it just that in any other language I find the compiler complaining about these stuff, just to make sure the programmer doesn't accidentally put a private where a public was there and vice versa. Also, I found a new one: -------------------------- final abstract class Bla { } -------------------------- Again, compiles perfectly, but why should want such a code to compile? Java doesn't allow all of these and, just as an example, it doesn't allow catching non-runtime exceptions that are never thrown (I'm not saying D should behave that way). Why? Just to make the code as clear as possible, without letting you say redundant or unnecessary things. Anyway, I think that, if we consider this a problem, it has a very low priority. Ary
Sep 08 2006