www.digitalmars.com         C & C++   DMDScript  

D - tolower conflict

reply Patrick Down <pat codemoon.com> writes:
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");
}
Jul 02 2002
parent reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:
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");
 }

Jul 03 2002
parent reply Patrick Down <pat codemoon.com> writes:
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");
 }


Jul 03 2002
parent reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:
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");
 }



Jul 05 2002
parent reply Patrick Down <pat codemoon.com> writes:
"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.
Jul 05 2002
parent reply "Walter" <walter digitalmars.com> writes:
"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.
Jul 07 2002
parent reply "anderson" <anderson firestar.com.au> writes:
"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.
Jul 08 2002
parent reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:
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


 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.

Jul 08 2002
parent reply "Walter" <walter digitalmars.com> writes:
"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.
Jul 08 2002
parent reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:
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.

Jul 09 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:agf603$jcs$1 digitaldaemon.com...
 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.  ;)

Someone (was it you?) posted the idea of enabling specification of aliases for symbols, this would enable easy (and explicit) replication of a symbol from one module into another. That should resolve the difficulties in your example.
Jul 09 2002
parent reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:
"Walter" <walter digitalmars.com> wrote in message
news:agfqj9$17g9$1 digitaldaemon.com...
 "Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
 news:agf603$jcs$1 digitaldaemon.com...
 Just let them clarify the import or hide an imported function, that


 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.


 Someone (was it you?) posted the idea of enabling specification of aliases
 for symbols, this would enable easy (and explicit) replication of a symbol
 from one module into another. That should resolve the difficulties in your
 example.

I think aliases on symbols are a good idea, (and I think it was me in fact) Yeah I guess this could work: import vector2; import vector3; alias vector2.dot dot; // pull them both into this module alias vector3.dot dot; // now the overloading works as expected int main() { vector3 a; vector2 b; float val = Dot(a,a) + Dot(b,b); return 0; } Some variant of import syntax would also work for this particular issue: import vector2; import vector3; import vector2.dot; import vector3.dot; Sean
Jul 09 2002
next sibling parent reply "Matthew Wilson" <matthew thedjournal.com> writes:
Most definitely. Surely this is analogous to the using ::ns::sym; C++
syntax, and should be used in just the same way, ie. from the using
declaration onwards any compilation unit sees all symbols of the same name
as equally "visible" resolving your original objection. Or am I missing
something?


"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:agghug$1v2m$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:agfqj9$17g9$1 digitaldaemon.com...
 "Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
 news:agf603$jcs$1 digitaldaemon.com...
 Just let them clarify the import or hide an imported function, that


 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



 compiler to be my mom.  Let me shoot myself in the foot if I need to.


 Someone (was it you?) posted the idea of enabling specification of


 for symbols, this would enable easy (and explicit) replication of a


 from one module into another. That should resolve the difficulties in


 example.

I think aliases on symbols are a good idea, (and I think it was me in

 Yeah I guess this could work:

 import vector2;
 import vector3;

 alias vector2.dot dot; // pull them both into this module
 alias vector3.dot dot;

 // now the overloading works as expected

 int main()
 {
     vector3 a;
     vector2 b;
     float val = Dot(a,a) + Dot(b,b);
     return 0;
 }

 Some variant of import syntax would also work for this particular issue:

 import vector2;
 import vector3;
 import vector2.dot;
 import vector3.dot;


 Sean

Jul 09 2002
parent reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:
Right, except it shouldn't be dependent on lexical order.

Sean

"Matthew Wilson" <matthew thedjournal.com> wrote in message
news:aggioi$1vpg$1 digitaldaemon.com...
 Most definitely. Surely this is analogous to the using ::ns::sym; C++
 syntax, and should be used in just the same way, ie. from the using
 declaration onwards any compilation unit sees all symbols of the same name
 as equally "visible" resolving your original objection. Or am I missing
 something?


 "Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
 news:agghug$1v2m$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:agfqj9$17g9$1 digitaldaemon.com...
 "Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
 news:agf603$jcs$1 digitaldaemon.com...
 Just let them clarify the import or hide an imported function, that


 them a way to resolve conflicts, and doesn't prevent people from




 reasonable things because you think it's good for them.  I don't




 my
 compiler to be my mom.  Let me shoot myself in the foot if I need




 ;)
 Someone (was it you?) posted the idea of enabling specification of


 for symbols, this would enable easy (and explicit) replication of a


 from one module into another. That should resolve the difficulties in


 example.

I think aliases on symbols are a good idea, (and I think it was me in

 Yeah I guess this could work:

 import vector2;
 import vector3;

 alias vector2.dot dot; // pull them both into this module
 alias vector3.dot dot;

 // now the overloading works as expected

 int main()
 {
     vector3 a;
     vector2 b;
     float val = Dot(a,a) + Dot(b,b);
     return 0;
 }

 Some variant of import syntax would also work for this particular issue:

 import vector2;
 import vector3;
 import vector2.dot;
 import vector3.dot;


 Sean


Jul 11 2002
next sibling parent reply "Matthew Wilson" <matthew thedjournal.com> writes:
It has to, surely?

"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:aglktd$m1i$1 digitaldaemon.com...
 Right, except it shouldn't be dependent on lexical order.

 Sean

 "Matthew Wilson" <matthew thedjournal.com> wrote in message
 news:aggioi$1vpg$1 digitaldaemon.com...
 Most definitely. Surely this is analogous to the using ::ns::sym; C++
 syntax, and should be used in just the same way, ie. from the using
 declaration onwards any compilation unit sees all symbols of the same


 as equally "visible" resolving your original objection. Or am I missing
 something?


 "Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
 news:agghug$1v2m$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:agfqj9$17g9$1 digitaldaemon.com...
 "Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
 news:agf603$jcs$1 digitaldaemon.com...
 Just let them clarify the import or hide an imported function,





 gives
 them a way to resolve conflicts, and doesn't prevent people from




 reasonable things because you think it's good for them.  I don't




 my
 compiler to be my mom.  Let me shoot myself in the foot if I need




 ;)
 Someone (was it you?) posted the idea of enabling specification of


 for symbols, this would enable easy (and explicit) replication of a


 from one module into another. That should resolve the difficulties




 your
 example.

I think aliases on symbols are a good idea, (and I think it was me in

 Yeah I guess this could work:

 import vector2;
 import vector3;

 alias vector2.dot dot; // pull them both into this module
 alias vector3.dot dot;

 // now the overloading works as expected

 int main()
 {
     vector3 a;
     vector2 b;
     float val = Dot(a,a) + Dot(b,b);
     return 0;
 }

 Some variant of import syntax would also work for this particular



 import vector2;
 import vector3;
 import vector2.dot;
 import vector3.dot;


 Sean



Jul 11 2002
parent "Sean L. Palmer" <seanpalmer earthlink.net> writes:
Why should it have to?

Don't limit yourself to what C and C++ offer you.  Look at C#; it also has
no dependence on lexical order of declarations.  So long as they're in the
same scope it's ok.  C++ does this too but only within a class declaration.

Maybe it should work like all the other D attributes.  Either

using mymodule.myfunction :

myfunction();

or

using mymodule.myfunction
{
    myfunction();
}

Sean


"Matthew Wilson" <matthew thedjournal.com> wrote in message
news:agloqe$pc5$1 digitaldaemon.com...
 It has to, surely?

 "Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
 news:aglktd$m1i$1 digitaldaemon.com...
 Right, except it shouldn't be dependent on lexical order.

 Sean

 "Matthew Wilson" <matthew thedjournal.com> wrote in message
 news:aggioi$1vpg$1 digitaldaemon.com...
 Most definitely. Surely this is analogous to the using ::ns::sym; C++
 syntax, and should be used in just the same way, ie. from the using
 declaration onwards any compilation unit sees all symbols of the same


 as equally "visible" resolving your original objection. Or am I



 something?



Jul 12 2002
prev sibling parent reply "Matthew Wilson" <matthew thedjournal.com> writes:
It has to, surely?

If not, doesn't this leave us in the same non-deterministic (or at least
unpredictable / invisible) position, whereby the introduction of a symbol
"lower down" in the particular scope's visibility causes
unforeseen/unintended side-effects to code that shouldn't be able to see it?

"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:aglktd$m1i$1 digitaldaemon.com...
 Right, except it shouldn't be dependent on lexical order.

 Sean

 "Matthew Wilson" <matthew thedjournal.com> wrote in message
 news:aggioi$1vpg$1 digitaldaemon.com...
 Most definitely. Surely this is analogous to the using ::ns::sym; C++
 syntax, and should be used in just the same way, ie. from the using
 declaration onwards any compilation unit sees all symbols of the same


 as equally "visible" resolving your original objection. Or am I missing
 something?


 "Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
 news:agghug$1v2m$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:agfqj9$17g9$1 digitaldaemon.com...
 "Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
 news:agf603$jcs$1 digitaldaemon.com...
 Just let them clarify the import or hide an imported function,





 gives
 them a way to resolve conflicts, and doesn't prevent people from




 reasonable things because you think it's good for them.  I don't




 my
 compiler to be my mom.  Let me shoot myself in the foot if I need




 ;)
 Someone (was it you?) posted the idea of enabling specification of


 for symbols, this would enable easy (and explicit) replication of a


 from one module into another. That should resolve the difficulties




 your
 example.

I think aliases on symbols are a good idea, (and I think it was me in

 Yeah I guess this could work:

 import vector2;
 import vector3;

 alias vector2.dot dot; // pull them both into this module
 alias vector3.dot dot;

 // now the overloading works as expected

 int main()
 {
     vector3 a;
     vector2 b;
     float val = Dot(a,a) + Dot(b,b);
     return 0;
 }

 Some variant of import syntax would also work for this particular



 import vector2;
 import vector3;
 import vector2.dot;
 import vector3.dot;


 Sean



Jul 11 2002
parent "Sean L. Palmer" <seanpalmer earthlink.net> writes:
Why should "upper" and "lower" have any special distinction?

Why should "prior" and "subsequent" have any special distinction?

It's either visible in the scope, or it's not.

Sean

"Matthew Wilson" <matthew thedjournal.com> wrote in message
news:aglot4$pgp$1 digitaldaemon.com...
 It has to, surely?

 If not, doesn't this leave us in the same non-deterministic (or at least
 unpredictable / invisible) position, whereby the introduction of a symbol
 "lower down" in the particular scope's visibility causes
 unforeseen/unintended side-effects to code that shouldn't be able to see

 "Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
 news:aglktd$m1i$1 digitaldaemon.com...
 Right, except it shouldn't be dependent on lexical order.

 Sean

 "Matthew Wilson" <matthew thedjournal.com> wrote in message
 news:aggioi$1vpg$1 digitaldaemon.com...
 Most definitely. Surely this is analogous to the using ::ns::sym; C++
 syntax, and should be used in just the same way, ie. from the using
 declaration onwards any compilation unit sees all symbols of the same


 as equally "visible" resolving your original objection. Or am I



 something?


 "Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
 news:agghug$1v2m$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:agfqj9$17g9$1 digitaldaemon.com...
 "Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
 news:agf603$jcs$1 digitaldaemon.com...
 Just let them clarify the import or hide an imported function,





 gives
 them a way to resolve conflicts, and doesn't prevent people from




 reasonable things because you think it's good for them.  I don't




 my
 compiler to be my mom.  Let me shoot myself in the foot if I






 to.
 ;)
 Someone (was it you?) posted the idea of enabling specification of


 for symbols, this would enable easy (and explicit) replication of





 symbol
 from one module into another. That should resolve the difficulties




 your
 example.

I think aliases on symbols are a good idea, (and I think it was me




 fact)
 Yeah I guess this could work:

 import vector2;
 import vector3;

 alias vector2.dot dot; // pull them both into this module
 alias vector3.dot dot;

 // now the overloading works as expected

 int main()
 {
     vector3 a;
     vector2 b;
     float val = Dot(a,a) + Dot(b,b);
     return 0;
 }

 Some variant of import syntax would also work for this particular



 import vector2;
 import vector3;
 import vector2.dot;
 import vector3.dot;


 Sean




Jul 12 2002
prev sibling parent "OddesE" <OddesE_XYZ hotmail.com> writes:
"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:agghug$1v2m$1 digitaldaemon.com...
<SNIP>
 I think aliases on symbols are a good idea, (and I think it was me in

 Yeah I guess this could work:

 import vector2;
 import vector3;

 alias vector2.dot dot; // pull them both into this module
 alias vector3.dot dot;

 // now the overloading works as expected

 Sean

Good ideas! I love it when everyone agrees! :) I especially like the notion of being able to alias any symbol to any other, it could be very handy for resolving all kinds of issues when porting or modifying code. -- Stijn OddesE_XYZ hotmail.com http://OddesE.cjb.net _________________________________________________ Remove _XYZ from my address when replying by mail
Jul 11 2002