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

[d-bugmail at puremagic.com]

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



--- Comment #2 from Manu <turkeyman at 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: -------