digitalmars.D.learn - Multiple attribute specifiers
- Ary Manzana (24/24) Sep 06 2006 If I write this inside a module:
- Chris Nicholson-Sauls (20/56) Sep 06 2006 Okay this is odd, indeed. I would expect an error from contradictory at...
- Steve Horne (27/38) Sep 06 2006 I'd guess it falls out of allowing several access modifier styles...
- Stewart Gordon (18/49) Sep 06 2006 When one protection attribute appears within an attribute block that
- Ary Manzana (8/58) Sep 07 2006 In some post of the "learn" list someone said the last attribute should
- Steve Horne (29/33) Sep 07 2006 If your referring to me, that's not 'should be' exactly.
- Stewart Gordon (20/37) Sep 07 2006 Can you remember anything at all about this post? Such as who wrote it,...
- Steve Horne (48/51) Sep 07 2006 I'm pretty sure he means me, so I'll just repost this with the
- Steve Horne (36/39) Sep 07 2006 The relevant bits from the original post, reposted and crossposted...
- Ary Manzana (18/59) Sep 08 2006 I finally think it's not a big deal, it just that in any other language
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
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: 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
Steve Horne <stephenwantshornenospam100 aol.com> On Wed, 06 Sep 2006 13:53:05 -0500, Chris Nicholson-Sauls <ibisbasenji gmail.com> wrote:Comments imbeded. Ary Manzana wrote: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.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.
Sep 06 2006
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
Stewart Gordon wrote:Ary Manzana wrote: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.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.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.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.Ary
Sep 07 2006
On Thu, 07 Sep 2006 09:25:15 -0300, Ary Manzana <asterite gmail.com> wrote:Stewart Gordon wrote: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.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.
Sep 07 2006
Ary Manzana wrote:Stewart Gordon wrote:<snip>Ary Manzana wrote:If I write this inside a module: -------------------------------------- public private int x;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>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.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.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.
Sep 07 2006
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
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
Steve Horne wrote:On Thu, 07 Sep 2006 19:31:01 +0100, Stewart Gordon <smjg_1998 yahoo.com> wrote: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. AryCan 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?
Sep 08 2006