[Issue 11900] Implicit cast of string literal -> char* causing ambiguous call

d-bugmail at puremagic.com d-bugmail at puremagic.com
Fri Jan 10 22:33:19 PST 2014


https://d.puremagic.com/issues/show_bug.cgi?id=11900


Jakob Ovrum <jakobovrum at gmail.com> changed:

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


--- Comment #1 from Jakob Ovrum <jakobovrum at 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: -------


More information about the Digitalmars-d-bugs mailing list