www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 900] New: changing import order causes type mismatch

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=900

           Summary: changing import order causes type mismatch
           Product: D
           Version: 1.004
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Keywords: rejects-valid
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla digitalmars.com
        ReportedBy: torhu yahoo.com


Tested with DMD 1.0 and 1.004 on winxp.

There are 4 files involved:

// palette.d
module palette;

struct RGB { }

=========================================
// color_inl.d
module color_inl;

//uncommenting this line will fix the problem
//import palette : RGB:

import color;

void _set_color(RGB* p) { }

=========================================
// color.d
module color;

// swapping the order of these two lines will also fix the problem
public import color_inl;
import palette : RGB;

=========================================
// dtest.d
import color;

void fade()
{
   RGB rgb;
   _set_color(&rgb);
}

void main() {}

========================================

C:\prog\test\D\bugtest>dmd test.d
test.d(6): function color_inl._set_color (int,RGB*) does not match parameter
types (int,RGB *)
test.d(6): Error: cannot implicitly convert expression (& rgb) of type RGB * to
RGB*


-- 
Jan 28 2007
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=900


torhu yahoo.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|rejects-valid               |





Are selective imports private by default or not?  The docs state that imports
are public by default, but also says that selective imports are "bound into the
current namespace".

I take it they are supposed to be private, which means this bug is really about
the compiler accepting invalid code, since color_inl.d and dtest.d are able to
use RGB without importing palette.d.


-- 
Jan 29 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=900






Imports are private by default, if the spec says anything else, create a bug
report for it.


-- 
Jan 29 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=900







The problem is that I don't know if "bound into the current namespace" implies
that it's also automatically exported as part of the importing module.

Probably it shouldn't imply that, since the point of selective imports seems to
be to avoid name conflicts in the importing module.

But this still confuses me, so I think there should be a clarification in the
docs.  At least so we know what is correct when the compiler is somewhere in
between.


-- 
Jan 29 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=900







 A couple of bug reports here that suggest that selective, static, and renamed
imports are meant to be be private.

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

The question remains whether this is intended, or not.  In DMD, they are
currently public.  Were they supposed to be private?  The docs don't say.


-- 
Apr 03 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=900


Leandro Lucarella <llucax gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |llucax gmail.com



PST ---
I think the spec is quite clear:

  [...]
  Public Imports

  By default, imports are private. [...]

http://www.digitalmars.com/d/1.0/module.html#ImportDeclaration

Static, renamed and selective import are all *import*, so it looks like they
all should be private by default (for the same reason basic imports are).

This bug is old and doesn't look very useful, I think it should be closed.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 13 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=900


Jesse Phillips <Jesse.K.Phillips+D gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Jesse.K.Phillips+D gmail.co
                   |                            |m



16:42:17 PDT ---
I seem to have run across this in DMD 2.042. Here a static assert fails with
the error:

=====================
C:\opt\dmd\windows\bin\..\..\src\phobos\std\typecons.d(424): Error: static
assert  (is(Tuple!(string,float) == Tuple!(string,float))) is false

C:\opt\dmd\windows\bin\..\..\src\phobos\std\typecons.d(413): 
instantiated from here: Tuple!(string,float)

C:\opt\dmd\windows\bin\..\..\src\phobos\std\typecons.d(423): 
instantiated from here: slice!(1,3)

C:\opt\dmd\windows\bin\..\..\src\phobos\std\typecons.d(420):
instantiated from here: Tuple!(int,string,float,double)

C:\opt\dmd\windows\bin\..\..\src\phobos\std\regex.d(260):
instantiated from here: Tuple!(string,string)

C:\opt\dmd\windows\bin\..\..\src\phobos\std\regex.d(280):
instantiated from here: opCall!(string)

C:\opt\dmd\windows\bin\..\..\src\phobos\std\regex.d(1519):
instantiated from here: Regex!(char).\test2.d(7):
instantiated from here: regex!(string)
===================

--------------------------
// Place string after import test2 to make this work
import std.string;
import test2;

void main() {
    new TestMe();
}
------------------------------

--------------------
module test2;

import std.regex;

class TestMe {
    void test(string input) {
        auto foo = !match(input, regex("fish")).empty;
    }
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 29 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=900




14:23:31 PDT ---
My import issue is no longer in DMD 2.043, but the original submission's code
still doesn't work.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 15 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=900


dawg dawgfoto.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |dawg dawgfoto.de
         Resolution|                            |INVALID



This is invalid because 'import palette : RGB;' introduces RGB as private
alias.
You cannot access it from color_inl.
Changing that to 'public import palette : RGB' will fix your problem.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 14 2012
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=900


dawg dawgfoto.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |



Sorry, I was using a wrong dmd version.
Changing it to 'public import palette : RGB' will fail because
of a forward reference error. This happens due to the cyclic import of color
and color_inc.

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