www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 1849] New: with() should cause shadowing errors if you use a member that's shadowed

reply d-bugmail puremagic.com writes:
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
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1849


bugzilla digitalmars.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement




------- Comment #1 from bugzilla digitalmars.com  2008-03-02 23:35 -------
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1849





------- Comment #2 from wbaxter gmail.com  2008-03-02 23:48 -------
(In reply to comment #1)

 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).



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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1849





------- Comment #3 from bugzilla digitalmars.com  2008-03-03 02:01 -------
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1849





------- Comment #4 from wbaxter gmail.com  2008-03-03 02:29 -------
(In reply to comment #3)

 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.



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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1849





------- Comment #5 from bugzilla digitalmars.com  2008-03-04 21:04 -------
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
prev sibling next sibling parent reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1849





------- Comment #6 from wbaxter gmail.com  2008-03-04 21:10 -------
(In reply to comment #5)

 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 04 2008
parent Christopher Wright <dhasenan gmail.com> writes:
d-bugmail puremagic.com wrote:

 http://d.puremagic.com/issues/show_bug.cgi?id=1849
 
 
 
 
 
 ------- Comment #6 from wbaxter gmail.com  2008-03-04 21:10 -------
 (In reply to comment #5)

 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.



If 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.
Mar 05 2008
prev sibling parent d-bugmail puremagic.com writes:
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


--- Comment #8 from Andrei Alexandrescu <andrei metalanguage.com> 2011-01-08
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