digitalmars.D.bugs - [Issue 3878] New: Arguments and attributes with the same name
- d-bugmail puremagic.com (42/42) Mar 04 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3878
- d-bugmail puremagic.com (8/9) Mar 04 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3878
- d-bugmail puremagic.com (16/16) Mar 08 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3878
- d-bugmail puremagic.com (6/6) Jun 29 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3878
- d-bugmail puremagic.com (8/8) Sep 30 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3878
- d-bugmail puremagic.com (17/19) Oct 02 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3878
- d-bugmail puremagic.com (10/16) Oct 03 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3878
- d-bugmail puremagic.com (23/38) Oct 03 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3878
- d-bugmail puremagic.com (7/7) Oct 15 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3878
- d-bugmail puremagic.com (16/16) Oct 17 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3878
- d-bugmail puremagic.com (33/109) Mar 21 2011 http://d.puremagic.com/issues/show_bug.cgi?id=3878
- d-bugmail puremagic.com (9/9) Mar 23 2013 http://d.puremagic.com/issues/show_bug.cgi?id=3878
http://d.puremagic.com/issues/show_bug.cgi?id=3878 Summary: Arguments and attributes with the same name Product: D Version: 2.041 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: DMD AssignedTo: nobody puremagic.com ReportedBy: bearophile_hugs eml.cc This D2 program compiles: class Foo { int x; this(int x) { x = x; } void inc(int x) { this.x += x; } } class Bar { int x; this() { x = 5; } } struct Spam { static int x; void inc(int x) { Spam.x += x; } } void main() {} The compiler has no problems in knowing what variables are each of those (and maybe a good IDE too can tell them apart well, and give different colors to arguments and attributes), but for the eye of a programmer that's not using such IDE that code is confusing enough (because the "this." is optional in D). I see two possible solutions to avoid that mess: The solution I prefer: the compiler can give an error when an argument has the same name of an attribute. This is more tidy. Less restricting solution: in only those cases, where there can be ambiguity for the eyes of a programmer, the compiler can require the use of "this.". Discussion: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=106970 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 04 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3878 A comment by Clemens (http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=106995 ) about the second idea:As soon as you have an instance variable x and a function parameter x, there will *always* be ambiguity (unless you don't use the parameter). Requiring the use of "this." amounts to disallowing access to the parameter x. Or do you suggest making the distinction based on whether x is used as an lvalue or a rvalue?<-- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 04 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3878 Don <clugdbug yahoo.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |clugdbug yahoo.com.au As I understand option(2) of this proposal, if a function parameter 'shadows' a member variable of the same name, it should be illegal to use that parameter as an lvalue. I think you're probably correct in claiming that any such code is highly likely to be a bug. If x is both a parameter and a member, then x = 3; should almost certainly be this.x = 3; -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 08 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3878 See related bug 4407 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jun 29 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3878 See also "Using Redundancies to Find Errors", by Yichen Xie and Dawson Engler, 2002: www.stanford.edu/~engler/p401-xie.pdf -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Sep 30 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3878 Stewart Gordon <smjg iname.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |smjg iname.com Summary|Arguments and attributes |Arguments and members with |with the same name |the same name The summary was confusing - many of us understand "attributes" to mean the keywords that qualify a declaration. It took me few moments to make sense of it.Less restricting solution: in only those cases, where there can be ambiguity for the eyes of a programmer, the compiler can require the use of "this.".It already is required when you want to access the member in such circumstances. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 02 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3878I don't know what cases you refer to. Probably it's required when there is ambiguity for the compiler; but I have said "for the eyes of a programmer". Human eyes are not as good as compilers. A good language as D needs to prevent human mistakes when possible. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------Less restricting solution: in only those cases, where there can be ambiguity for the eyes of a programmer, the compiler can require the use of "this.".It already is required when you want to access the member in such circumstances.
Oct 03 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3878If a function parameter or local variable has the same name as a member of the class/struct/union in which it is defined, then in order to access the latter within the former's scope one must use "this.". Isn't that obvious?I don't know what cases you refer to.Less restricting solution: in only those cases, where there can be ambiguity for the eyes of a programmer, the compiler can require the use of "this.".It already is required when you want to access the member in such circumstances.Probably it's required when there is ambiguity for the compiler; but I have said "for the eyes of a programmer".So you think that "this." should be required for all accesses to members even when there's no ambiguity? This could make code rather cluttered.Human eyes are not as good as compilers. A good language as D needs to prevent human mistakes when possible.You mean like accidentally naming a local variable the same as a member of the class, except that at the same time you forget to declare it? The real solution to the original issue would be to (a) invent an explicit notation to access a local variable or function parameter (b) make it mandatory if it's ambiguous with anything else. But what would the scope of "anything else" be? * Just members of the class? * Members of the class and any of its outer classes? * Anything declared in the same module that is accessible from within the function? * Anything declared anywhere in the import tree that is accessible from within the function? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 03 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3878 12:41:15 PDT --- Here we could benefit from const parameters by default. Though this won't help in a case when local variable shadows member. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 15 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3878 In this enhancement request I am asking for ideas to avoid a common but specific kind of bug. One idea (not mine) to avoid some of those bugs is to introduce the this.fieldname syntax for method argument (type is optional and it may be different from the field type). In the constructor the argument assigns directly to the field: class Foo { int x; this(this.x) {} void inc(int x) { this.x += x; } } -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 17 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3878 A simpler solution are classes with automatic constructors: class Foo { string x; int y = 1; } void main() { Foo f1 = new Foo(); // Good Foo f2 = new Foo("hello"); // Good Foo f3 = new Foo("hello", 10); // Good } Some comments from a discussion thread: ----------------- Daniel Gibson:----------------- Don:A simpler solution are classes with automatic constructors: class Foo { string x; int y = 1; } void main() { Foo f1 = new Foo(); // Good Foo f2 = new Foo("hello"); // Good Foo f3 = new Foo("hello", 10); // Good } What kind of problems are caused by this? :-)You'd have to know the order in that the members are defined in the class (and you may not change the order). Just imagine class Foo { int bla; int baz; } new Foo(42, 3); // what is bla, what is baz? and then you decide "uh I'd prefer to have my class members ordered alphabetically" and *bamm* all you code silently breaks. having a this(this.bla, this.baz) {} would clearly document which argument in the constructor belongs to which class member and the class members ordering wouldn't matter.I agree. But unfortunately, the idea is a relatively complicated feature with a lot of special cases. For example, this(this.bla, this.bla){} and what if the class contains a union and you set multiple members of it? The whole thing is actually quite messy. It's not _terrible_, but it's far from trivial, and it's more complicated than some far more powerful and useful language features.----------------- KennyTM~:----------------- Daniel Gibson:I agree. But unfortunately, the idea is a relatively complicated feature with a lot of special cases. For example, this(this.bla, this.bla){}'int f(int x, int x) {}' is a syntax error. So should 'this(this.x, this.x){}'.----------------- Don:'int f(int x, int x) {}' is a syntax error. So should 'this(this.x, this.x){}'.and probably this(this.x, x){}It's not that it's complicated, it's that for structs, the ordering of their members is part of the public interface. For classes, the members are not public.----------------- KennyTM~:and probably this(this.x, x){}Exactly. That's why it's messier than it first appears. My point is -- people tend to think things like this are trivial features because they are not very powerful; and conversely, they think that powerful features must be complicated. But that's really misleading. 'pure', for example, is roughly the same level of implementation complexity as this feature.----------------- Overall I think the syntax this(this.x){} causes less troubles (class field keep being private, their order doesn't need to become public), while avoiding the bug that's the main topic of this enhancement request. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------and probably this(this.x, x){}Yes. This is handled by the AST transform (lowering) too. this(this.x, int x) { statements; } becomes this(typeof(this.x) x, int x) { this.x = x; statements; } which will complain Error: constructor x.Foo.this parameter this.x is already defined as expected.
Mar 21 2011
http://d.puremagic.com/issues/show_bug.cgi?id=3878 This enhancement request packs two different things: a request for an error message, and an alternative request for syntax sugar. To manage the two ideas it's better to split them in two. So this ER is just about the error message. The other half is in the new Issue 9801. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 23 2013