[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