digitalmars.D.bugs - [Issue 1849] New: with() should cause shadowing errors if you use a member that's shadowed
- d-bugmail puremagic.com (48/48) Feb 18 2008 http://d.puremagic.com/issues/show_bug.cgi?id=1849
- d-bugmail puremagic.com (10/10) Mar 02 2008 http://d.puremagic.com/issues/show_bug.cgi?id=1849
- d-bugmail puremagic.com (10/13) Mar 02 2008 http://d.puremagic.com/issues/show_bug.cgi?id=1849
- d-bugmail puremagic.com (6/6) Mar 03 2008 http://d.puremagic.com/issues/show_bug.cgi?id=1849
- d-bugmail puremagic.com (11/14) Mar 03 2008 http://d.puremagic.com/issues/show_bug.cgi?id=1849
- d-bugmail puremagic.com (5/5) Mar 04 2008 http://d.puremagic.com/issues/show_bug.cgi?id=1849
- d-bugmail puremagic.com (10/12) Mar 04 2008 http://d.puremagic.com/issues/show_bug.cgi?id=1849
- Christopher Wright (12/31) Mar 05 2008 If you could explicitly say that something is in an external scope, that...
- d-bugmail puremagic.com (16/16) Jan 08 2011 http://d.puremagic.com/issues/show_bug.cgi?id=1849
http://d.puremagic.com/issues/show_bug.cgi?id=1849 Summary: with() should cause shadowing errors if you use a member that's shadowed Product: D Version: 1.025 Platform: PC OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: bugzilla digitalmars.com ReportedBy: wbaxter gmail.com Sorry for the horrible summary. Kudos to anyone who can think of a better one. Issue is this: ---- module shadow2; struct Foo { static Foo opCall(int numRows, int numCols) { Foo R; with (R) { numRows_ = numRows; numCols_ = numRows; } return R; } int numRows() { return numRows_; } int numCols() { return numCols_; } private: int numRows_ = -1; int numCols_ = -1; } void main() { auto M = Foo(10,20); assert(M.numRows == -1, "numRows Shouldn't be -1, actually"); assert(M.numCols == -1, "numCols Shouldn't be -1, actually"); assert(M.numRows == 10, "numRows Should be 10 but it isn't"); assert(M.numCols == 20, "numCols Should be 20 but it isn't"); } ---- What happens is the with() there in the static opCall causes R.numRows() to shadow the parameter named 'numRows'. So you're actually just setting numRows_ to what it already was. This is pretty evil that this happens silently, so I think it should generate a shadowing error. But the tricky part is that error should only be generated if you try to *use* a shadowed variable. If errors were triggered even when no shadowed variable was used then with() could become practically useless because such many such "potential shadowings". --
Feb 18 2008
http://d.puremagic.com/issues/show_bug.cgi?id=1849 bugzilla digitalmars.com changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |enhancement The problem is even if the compiler did generate a warning, it would be problematical because one of the whole points of with is to do this (in a scoped manner, of course). --
Mar 02 2008
http://d.puremagic.com/issues/show_bug.cgi?id=1849The problem is even if the compiler did generate a warning, it would be problematical because one of the whole points of with is to do this (in a scoped manner, of course).You could say the same thing about plain-old {..} scopes, though. The whole point of a scope is to create a new (scoped) namespace, and yet D doesn't allow shadowing in those cases. At least I don't *think* you're saying that the point of with() is to shadow variables in outer scopes. If that's what you're saying then I guess I just don't really agree that that's a desirable thing. --
Mar 02 2008
http://d.puremagic.com/issues/show_bug.cgi?id=1849 With the shadowing rules as they exist, it's a very local edit to change the name of something. But with with shadowing, it's not a local edit - you're looking at changing the member names, or names in some enclosing scope. --
Mar 03 2008
http://d.puremagic.com/issues/show_bug.cgi?id=1849With the shadowing rules as they exist, it's a very local edit to change the name of something. But with with shadowing, it's not a local edit - you're looking at changing the member names, or names in some enclosing scope.Right, which is why I suggest only issuing the shadowing error if the member doing the shadowing is actually used inside the with{} block. It's very dangerous the way it is. Adding a member to an object in file A.d could cause behavior of code in B.d to change, without creating any sort of compiler errors. That seems to be the kind of hijacking effect that usually gets you up in arms, but here you don't seem so concerned about it for some reason. --
Mar 03 2008
http://d.puremagic.com/issues/show_bug.cgi?id=1849 I agree it can be a problem, and some people argue that the with itself is inherently a bad construct for such reasons. They might be right. --
Mar 04 2008
http://d.puremagic.com/issues/show_bug.cgi?id=1849I agree it can be a problem, and some people argue that the with itself is inherently a bad construct for such reasons. They might be right.They may be. If there were a way to do "selective with" like selective import I would probably use that. with(BigObject : member, other_member) { ... } Or if I could alias dot expressions like: alias foo.bar bar then I wouldn't be tempted to use 'with' as often. --
Mar 04 2008
d-bugmail puremagic.com wrote:http://d.puremagic.com/issues/show_bug.cgi?id=1849If you could explicitly say that something is in an external scope, that would also help. For instance: struct Foo { int a; } Foo myStruct; int a = 15; with (myStruct) { a = .a; // myStruct.a == 15 } Or simply saying any ambiguity is a compile-time error.I agree it can be a problem, and some people argue that the with itself is inherently a bad construct for such reasons. They might be right.They may be. If there were a way to do "selective with" like selective import I would probably use that. with(BigObject : member, other_member) { ... } Or if I could alias dot expressions like: alias foo.bar bar then I wouldn't be tempted to use 'with' as often.
Mar 05 2008
http://d.puremagic.com/issues/show_bug.cgi?id=1849 Andrei Alexandrescu <andrei metalanguage.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |andrei metalanguage.com Resolution| |FIXED 15:13:52 PST --- 2.051 refuses compilation with test.d(8): Error: with symbol shadow2.Foo.numRows is shadowing local symbol shadow2.Foo.opCall.numRows test.d(9): Error: with symbol shadow2.Foo.numRows is shadowing local symbol shadow2.Foo.opCall.numRows -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 08 2011