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


-- 

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


-- 

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.


-- 

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.


-- 

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.


-- 

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.


-- 

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.


-- 

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.

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: -------