[Issue 7372] Error provides too little information to diagnose the problem (error: undefined identifier)

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=7372


Leandro Lucarella <leandro.lucarella at sociomantic.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|rejects-valid               |diagnostic
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |
            Summary|(Regression git) wrong      |Error provides too little
                   |error: undefined identifier |information to diagnose the
                   |                            |problem (error: undefined
                   |                            |identifier)
           Severity|regression                  |normal


--- Comment #2 from Leandro Lucarella <leandro.lucarella at sociomantic.com> 2012-01-27 04:00:32 PST ---
(In reply to comment #1)
> This is not a bug.
> 
> From the spec: "Unlike a template instantiation, a template mixin's body is
> evaluated within the scope where the mixin appears, not where the template
> declaration is defined."
> 
> The default for imports is private, so m1.bug is not visible to m.C.

OK, so the case with the alias works because aliases are public by default,
right? Then using private alias m1.bug bug; I get this error:
m2.d(7): Error: module m m2.bug is private

Which describes the problem a little better. I will reopen this (lowering the
importance) to keep in mind the error message should be improved. The current
error gives no NO clue about the real location of the problem, which should be
the instantiation site, I think.

The "private alias" error is a little better in that regard but could be more
specific too. This is the main reason why this problem was SO hard to reduce to
a small test case. I was extremely hard to find out where the root problem was
because the error is triggered in the template, which in the real code is
instantiated from many places.

Besides that, I think this is a really nasty corner case then. So using a mixin
will require either:

1) Pollute the user's namespace by publicly importing everything the template
use
2) Asking the user to know the details of the mixin implementation and import
things according.

It there any other solution to this problem that doesn't have those 2 problems?
I guess doing the imports INSIDE the template would be an option, thus
polluting only the class name space and not the entire module, but there is
still pollution going on.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------