Sending this again, got an error the first time and it appears like it was not sent.

On 2012-02-04 21:48, Simen Kjærås wrote:
> I see. There's a hint in the error message: "function expected [...],
> not module". Struct is the name of a module, so the compiler thinks
> you want to access something inside it. If you want 'Struct' to refer
> to the type, you must use selective import[1]:
>
> import Struct : Struct;

I see, thanks, that does solve the problem. It is slightly confusing that you don't get this kind of error for "Foo" in "Bar.d", though (compiler seems to understand that I mean the class "Foo" rather than the module "Foo" in this code: "_foo = new Foo(Struct(1))").

Also, is this really ambiguous? Are there any cases where you can have a module name followed by a parentheses, i.e. "<module>("?


> I cannot seem to recreate this error message. Which version of the
> compiler are you using?

I'm using gdc-4.6 (Debian 4.6.2-4).
Using the Struct from above I can easily recreate the error:
struct Struct {
  int baz;
  bool opEquals(const Struct s) const {
    return baz == s.baz;
  }
}

On Sun, 05 Feb 2012 11:58:40 +0100, Vidar Wahlberg <canidae@exent.net> wrote:

> Also, is this really ambiguous? Are there any cases where you can have a module name followed by a parentheses, i.e. "<module>("?

Not that I know.


>  > I cannot seem to recreate this error message. Which version of the
>  > compiler are you using?
>
> I'm using gdc-4.6 (Debian 4.6.2-4).
> Using the Struct from above I can easily recreate the error:
> struct Struct {
>    int baz;
>    bool opEquals(const Struct s) const {
>      return baz == s.baz;
>    }
> }

Ah. That's the equivalent of DMD 2.054. I don't have that installed, but
it may be that this feature was not added until after that.

Fix: install GDC 4.6.1: https://bitbucket.org/goshawk/gdc/downloads

Workaround: Use a templated opEquals:

struct Struct {
    int baz;
    bool opEquals()(const Struct s) const {
        return baz == s.baz;
    }
}

Hope this works.

On 2012-02-05 14:16, Simen Kjærås wrote:
> On Sun, 05 Feb 2012 11:58:40 +0100, Vidar Wahlberg <canidae@exent.net>
> wrote:
>> Also, is this really ambiguous? Are there any cases where you can have
>> a module name followed by a parentheses, i.e. "<module>("?
>
> Not that I know.

Possibly something that could make the language slightly more newbie friendly here, then. For now I'll just keep the filenames in lowercase so i "import struct;" rather than "import Struct;" (I see the norm for D is to keep the filenames in lowercase, might as well follow it).

Adding a note about GDC (4.6.2) here:
It appears like it ignores "module <name>;" and always use the filename for module name (or I've misunderstood what "module" is used for). If I create a file "Foo.d" which contains "module foo;", then in any other file I wish to include module "foo" in I must write "include Foo;", not "include foo;".


>> I'm using gdc-4.6 (Debian 4.6.2-4).
>
> Ah. That's the equivalent of DMD 2.054. I don't have that installed, but
> it may be that this feature was not added until after that.
>
> Fix: install GDC 4.6.1: https://bitbucket.org/goshawk/gdc/downloads

I'm running GDC 4.6.2, not 4.6.0 (I just pasted output from "gdc-4.6 --version", I could've made it clearer), downgrading probably won't help me.


> Workaround: Use a templated opEquals:
>
> struct Struct {
> int baz;
> bool opEquals()(const Struct s) const {
> return baz == s.baz;
> }
> }
>
> Hope this works.

Yes, it does. I have to read a bit about templating as I don't understand exactly what that "()" means, but it did solve my problem, thanks!

"Vidar Wahlberg" <canidae@exent.net> wrote in message news:jgm2qk$c2g$1@digitalmars.com...
> Adding a note about GDC (4.6.2) here:
> It appears like it ignores "module <name>;" and always use the filename
> for module name (or I've misunderstood what "module" is used for). If I
> create a file "Foo.d" which contains "module foo;", then in any other file
> I wish to include module "foo" in I must write "include Foo;", not
> "include foo;".

The names only need to match if the compiler/build tool has to find the
module itself.  If you call the compiler with all modules listed:
gdc bar.d Foo.d etc.d
then it should be able to work it out.  (This is how it works with dmd,
anyway.  GDC is probably the same)

On 2012-02-05 15:19, Daniel Murphy wrote:
> The names only need to match if the compiler/build tool has to find the
> module itself.  If you call the compiler with all modules listed:
> gdc bar.d Foo.d etc.d
> then it should be able to work it out.  (This is how it works with dmd,
> anyway.  GDC is probably the same)

Actually, that is what I do. GDC does not seem to figure it out:
naushika:~/tmp> cat Foo.d
module foo;
...
naushika:~/tmp> gdc-4.6 bar.d Foo.d baz.d
bar.d:2: Error: module foo is in file 'foo.d' which cannot be read
import path[0] = /usr/include/d2/4.6/x86_64-linux-gnu
import path[1] = /usr/include/d2/4.6
naushika:~/tmp> mv Foo.d foo.d
naushika:~/tmp> gdc-4.6 bar.d foo.d baz.d
naushika:~/tmp>

I guess you've found a bug then. :)

"Vidar Wahlberg" <canidae@exent.net> wrote in message news:jgm7sh$k4u$1@digitalmars.com...
> On 2012-02-05 15:19, Daniel Murphy wrote:
>> The names only need to match if the compiler/build tool has to find the
>> module itself.  If you call the compiler with all modules listed:
>> gdc bar.d Foo.d etc.d
>> then it should be able to work it out.  (This is how it works with dmd,
>> anyway.  GDC is probably the same)
>
> Actually, that is what I do. GDC does not seem to figure it out:
> naushika:~/tmp> cat Foo.d
> module foo;
> ...
> naushika:~/tmp> gdc-4.6 bar.d Foo.d baz.d
> bar.d:2: Error: module foo is in file 'foo.d' which cannot be read
> import path[0] = /usr/include/d2/4.6/x86_64-linux-gnu
> import path[1] = /usr/include/d2/4.6
> naushika:~/tmp> mv Foo.d foo.d
> naushika:~/tmp> gdc-4.6 bar.d foo.d baz.d
> naushika:~/tmp>