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




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 "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




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.


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




 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.


 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
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




 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.


 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 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




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

 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.


 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 11 2002
parent "Sean L. Palmer" <seanpalmer earthlink.net> writes:
Why should it have to?


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




 name

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






missing

 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




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

 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.


 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 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


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




 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

 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.


 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 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


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


<SNIP>

 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