www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 11900] New: Implicit cast of string literal -> char* causing ambiguous call

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

           Summary: Implicit cast of string literal -> char* causing
                    ambiguous call
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: turkeyman gmail.com



2 overloads exist:
  void func(const(char)* str);
  void func(const(char)[] str);

Called with literal string:
  func("literal");

Complains; matches both, I don't think this is right...

Calles with a 'string':
  string x = "not literal";
  func(s);

Matches the array version, as expected.


I appreciate the convenience of the automatic string literal -> const(char)*
cast. But in this case, surely it should just choose the array version of the
function, like it does when calling with a 'string' variable?
The convenience should be just that, a convenience, not a hard rule...?

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 10 2014
next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11900


Jakob Ovrum <jakobovrum gmail.com> changed:

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



---


 2 overloads exist:
   void func(const(char)* str);
   void func(const(char)[] str);


It seems like the domain of overloading more-so than string literal behaviour;
I think it would require the addition of a special case rule to the overload
resolution rule set. I could be wrong; maybe there are other cases where it is
ambiguous (type inference? IFTI?).

I tend to think that this overload set is bad interface design, so the
motivation for the language change is questionable (but I'm not necessarily
against it). Typically I see these overloads used for covering up a costly
"dumb" `toStringz` conversion, which I think is really smelly design, but it
may be that we have no appealing alternative. Maybe we should work on
smartening up `toStringz` to automatically detect string literals and other
guaranteed null-terminated allocations, or maybe we should add a
std.typecons.CString type constructor so the user can guarantee
null-termination manually.

Anyway, just an observation, I'm not necessarily against the proposed amendment
as long as it's not done in a knee-jerk fashion (such as silently adding a
special case to DMD without updating the spec).

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 10 2014
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11900








 2 overloads exist:
   void func(const(char)* str);
   void func(const(char)[] str);


 
 It seems like the domain of overloading more-so than string literal behaviour;
 I think it would require the addition of a special case rule to the overload
 resolution rule set. I could be wrong; maybe there are other cases where it is
 ambiguous (type inference? IFTI?).
 
 I tend to think that this overload set is bad interface design, so the
 motivation for the language change is questionable (but I'm not necessarily
 against it). Typically I see these overloads used for covering up a costly
 "dumb" `toStringz` conversion, which I think is really smelly design, but it
 may be that we have no appealing alternative. Maybe we should work on
 smartening up `toStringz` to automatically detect string literals and other
 guaranteed null-terminated allocations, or maybe we should add a
 std.typecons.CString type constructor so the user can guarantee
 null-termination manually.
 
 Anyway, just an observation, I'm not necessarily against the proposed amendment
 as long as it's not done in a knee-jerk fashion (such as silently adding a
 special case to DMD without updating the spec).


Well it's kinda like you say, this overload set is very common, if you have a C
function, and you want to produce a D wrapper which receives a string and calls
through using toStringz. Otherwise you find yourself typing toStringz all over
the place, and it interferes with fp/delegates/generic code that deals with
strings.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 10 2014
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11900




---


 Well it's kinda like you say, this overload set is very common, if you have a C
 function, and you want to produce a D wrapper which receives a string and calls
 through using toStringz.


The ambiguity with string literal arguments probably means it's not overly
common at this stage, but regardless, its popularity does not justify its use.
We have no obligation to make concessions to enable bad code.


 Otherwise you find yourself typing toStringz all over
 the place, and it interferes with fp/delegates/generic code that deals with
 strings.


Yes, this is an unappealing alternative. I just think/hope it's not the only
alternative.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 10 2014
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11900








 Well it's kinda like you say, this overload set is very common, if you have a C
 function, and you want to produce a D wrapper which receives a string and calls
 through using toStringz.


 
 The ambiguity with string literal arguments probably means it's not overly
 common at this stage, but regardless, its popularity does not justify its use.
 We have no obligation to make concessions to enable bad code.


How is it a concession? It seems to me like the concession was already made to
make interacting with C functions easier. I'd say if anything, this is a bug
that stems from that decision.
There's nowhere else in D where a dynamic array can implicitly convert to a
pointer... why does it happen ONLY in the case of a string literal?

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 11 2014
prev sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11900




---






 Well it's kinda like you say, this overload set is very common, if you have a C
 function, and you want to produce a D wrapper which receives a string and calls
 through using toStringz.


 
 The ambiguity with string literal arguments probably means it's not overly
 common at this stage, but regardless, its popularity does not justify its use.
 We have no obligation to make concessions to enable bad code.


 
 How is it a concession? It seems to me like the concession was already made to
 make interacting with C functions easier. I'd say if anything, this is a bug
 that stems from that decision.


It complicates overloading rules.


 There's nowhere else in D where a dynamic array can implicitly convert to a
 pointer... why does it happen ONLY in the case of a string literal?


String literals are not dynamic arrays of a particular type. They are
polysemous: they can be UTF-8, UTF-16 or UTF-32 strings; to wit, there is no
place in the language where implicit conversion happens between dynamic arrays
of different code unit element types, either.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 11 2014