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


--- Comment #0 from Manu <turkeyman gmail.com> 2014-01-10 19:09:45 PST ---
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


--- Comment #1 from Jakob Ovrum <jakobovrum gmail.com> 2014-01-10 22:33:06 PST
---
(In reply to comment #0)
 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



--- Comment #2 from Manu <turkeyman gmail.com> 2014-01-10 22:59:14 PST ---
(In reply to comment #1)
 (In reply to comment #0)
 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



--- Comment #3 from Jakob Ovrum <jakobovrum gmail.com> 2014-01-10 23:22:19 PST
---
(In reply to comment #2)
 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



--- Comment #4 from Manu <turkeyman gmail.com> 2014-01-11 01:21:24 PST ---
(In reply to comment #3)
 (In reply to comment #2)
 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



--- Comment #5 from Jakob Ovrum <jakobovrum gmail.com> 2014-01-11 01:34:43 PST
---
(In reply to comment #4)
 (In reply to comment #3)
 (In reply to comment #2)
 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