The program below generates the following error.

string.d(371): function tolower symbol string.tolower conflicts with ctype.tolower at ctype.d(23)

Why do the two conflict when the two function signatures are different?

import string;
import ctype;

int main(char[][] arg)
{
  assert(tolower("Fred") == "fred");
}

Because you're importing them both?

Seems the compiler would allow them to be imported but would force you to explicitly qualify which one you mean when calling tolower.

Sean

"Patrick Down" <pat@codemoon.com> wrote in message news:Xns923FEB35B77B9patcodemooncom@63.105.9.61...
> The program below generates the following error.
>
> string.d(371): function tolower symbol string.tolower conflicts with
> ctype.tolower at ctype.d(23)
>
> Why do the two conflict when the two function signatures are different?
>
> import string;
> import ctype;
>
> int main(char[][] arg)
> {
>   assert(tolower("Fred") == "fred");
> }

The tolower in ctype.d is
char tolower(char c)

and the tolower in string.d is
char[] tolower(char[] s)

One takes a char and the other char[].
They should be different functions.

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in news:afu7nh$11pu$1@digitaldaemon.com:

> Because you're importing them both?
> 
> Seems the compiler would allow them to be imported but would force you to explicitly qualify which one you mean when calling tolower.
> 
> Sean
> 
> "Patrick Down" <pat@codemoon.com> wrote in message news:Xns923FEB35B77B9patcodemooncom@63.105.9.61...
>> The program below generates the following error.
>>
>> string.d(371): function tolower symbol string.tolower conflicts with
>> ctype.tolower at ctype.d(23)
>>
>> Why do the two conflict when the two function signatures are different?
>>
>> import string;
>> import ctype;
>>
>> int main(char[][] arg)
>> {
>>   assert(tolower("Fred") == "fred");
>> }
> 
> 

Seems like a compiler bug.  If they were both declared in the same (local) module, it wouldn't be a problem.

Sean

"Patrick Down" <pat@codemoon.com> wrote in message news:Xns92404E51B6026patcodemooncom@63.105.9.61...
> The tolower in ctype.d is
> char tolower(char c)
>
> and the tolower in string.d is
> char[] tolower(char[] s)
>
> One takes a char and the other char[].
> They should be different functions.
>
> "Sean L. Palmer" <seanpalmer@earthlink.net> wrote in news:afu7nh$11pu$1@digitaldaemon.com:
>
> > Because you're importing them both?
> >
> > Seems the compiler would allow them to be imported but would force you to explicitly qualify which one you mean when calling tolower.
> >
> > Sean
> >
> > "Patrick Down" <pat@codemoon.com> wrote in message news:Xns923FEB35B77B9patcodemooncom@63.105.9.61...
> >> The program below generates the following error.
> >>
> >> string.d(371): function tolower symbol string.tolower conflicts with
> >> ctype.tolower at ctype.d(23)
> >>
> >> Why do the two conflict when the two function signatures are different?
> >>
> >> import string;
> >> import ctype;
> >>
> >> int main(char[][] arg)
> >> {
> >>   assert(tolower("Fred") == "fred");
> >> }

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in news:ag41cf$ncu$1@digitaldaemon.com:

> Seems like a compiler bug.  If they were both declared in the same (local) module, it wouldn't be a problem.
> 
> Sean
> 

I realized that Walter had already answered this one in an earlier post.

"Walter" <walter@digitalmars.com> wrote in news:ach4qs$1mpq$1@digitaldaemon.com:
>I chose the path that if it's ambiguous at all, generate an error. I think in the end code will be much clearer if it is disambiguated with module prefixes like string.toString(...), etc.


It seems the rule is (Walter correct me if I am wrong):

1. Polymorphic functions in the same module or class are ok.
2. Polymorphic functions between two different modules or
a class and module are considered ambiguous and need qualification.

"Patrick Down" <pat@codemoon.com> wrote in message news:Xns924251B688C23patcodemooncom@63.105.9.61...
> It seems the rule is (Walter correct me if I am wrong):
>
> 1. Polymorphic functions in the same module or class are ok.
> 2. Polymorphic functions between two different modules or
> a class and module are considered ambiguous and need qualification.

Yes, you're correct. I believe it is confusing and error prone to allow overloading a function across multiple modules, and so such is an error. Someone reading the code should not need to worry about some overloaded version of a function being inadvertantly pulled in from some unsuspected import. This should be better documented.

"Walter" <walter@digitalmars.com> wrote in message news:agb945$24ll$1@digitaldaemon.com...
>
> "Patrick Down" <pat@codemoon.com> wrote in message news:Xns924251B688C23patcodemooncom@63.105.9.61...
> > It seems the rule is (Walter correct me if I am wrong):
> >
> > 1. Polymorphic functions in the same module or class are ok.
> > 2. Polymorphic functions between two different modules or
> > a class and module are considered ambiguous and need qualification.
>
> Yes, you're correct. I believe it is confusing and error prone to allow overloading a function across multiple modules, and so such is an error. Someone reading the code should not need to worry about some overloaded version of a function being inadvertantly pulled in from some unsuspected import.

I agree.

> This should be better documented.


I agree, but there are lots of areas in D that need more documentation. That'll grow as more users pickup D. I'm not saying that you shouldn't document this. I'm just saying that documention will improve over time.

Just more special cases.  One more trivia you have to remember when programming D.  It's language baggage.

Sean


"anderson" <anderson@firestar.com.au> wrote in message news:agc92n$4pm$1@digitaldaemon.com...
>
> "Walter" <walter@digitalmars.com> wrote in message news:agb945$24ll$1@digitaldaemon.com...
> >
> > "Patrick Down" <pat@codemoon.com> wrote in message news:Xns924251B688C23patcodemooncom@63.105.9.61...
> > > It seems the rule is (Walter correct me if I am wrong):
> > >
> > > 1. Polymorphic functions in the same module or class are ok.
> > > 2. Polymorphic functions between two different modules or
> > > a class and module are considered ambiguous and need qualification.
> >
> > Yes, you're correct. I believe it is confusing and error prone to allow overloading a function across multiple modules, and so such is an error. Someone reading the code should not need to worry about some overloaded version of a function being inadvertantly pulled in from some
unsuspected
> > import.
>
> I agree.
>
> > This should be better documented.
>
>
> I agree, but there are lots of areas in D that need more documentation. That'll grow as more users pickup D. I'm not saying that you shouldn't document this. I'm just saying that documention will improve over time.

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:agcma4$ith$1@digitaldaemon.com...
> Just more special cases.  One more trivia you have to remember when programming D.  It's language baggage.

It depends on your viewpoint whether it is a special case or not <g>. I think it falls out naturally from the lookup rules, although it might be unexpected since C++ doesn't work that way.

Think about this:

I make a vmath.d module and put in a vector3 struct:

struct vector3 { float x,y,z; }

and a dot product function

float dot(vector3 a, vector3 b) { return a.x*b.x+a.y*b.y+a.z*b.z; }

Now later I find that I need a vector2 also:

struct vector2 { float x,y; }

and that needs a dot product function also

float dot(vector2 a, vector2 b) { return a.x*b.x+a.y*b.y; }

Then I make main.d and it does this:

import vmath.d;

int main()
{
    vector3 v1 = {0,1,0};
    vector3 v2 = {0.5,0.5,0.5};
    printf("%f", dot(v1,v2));
    vector2 t1 = {0,1};
    vector2 t2 = {0.5,0.5};
    printf("%f", dot(t1,t2));
}

Everything is fine.  Now later I decide that vmath.d is getting too cluttered and I move those two into their own modules, vector2.d and vector3.d.  And blammo nothing works anymore, I have to rewrite all my code that uses dot function and split it into two functions dot3 and dot2, just because of this silly little special case.

Just let them clarify the import or hide an imported function, that gives them a way to resolve conflicts, and doesn't prevent people from doing reasonable things because you think it's good for them.  I don't want my compiler to be my mom.  Let me shoot myself in the foot if I need to.  ;)

Sean



"Walter" <walter@digitalmars.com> wrote in message news:agdm4f$1imd$1@digitaldaemon.com...
>
> "Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:agcma4$ith$1@digitaldaemon.com...
> > Just more special cases.  One more trivia you have to remember when programming D.  It's language baggage.
>
> It depends on your viewpoint whether it is a special case or not <g>. I think it falls out naturally from the lookup rules, although it might be unexpected since C++ doesn't work that way.
>
>