Kill implicit joining of adjacent strings
Michel Fortin
michel.fortin at michelf.com
Thu Nov 11 12:15:03 PST 2010
On 2010-11-11 15:05:08 -0500, Rainer Deyke <rainerd at eldwood.com> said:
> On 11/11/2010 06:06, Michel Fortin wrote:
>> On 2010-11-10 23:51:38 -0500, Rainer Deyke <rainerd at eldwood.com> said:
>>
>>> As it turns out, the joining of adjacent strings is a critical feature.
>>> Consider the following:
>>> f("a" "b");
>>> f("a" ~ "b");
>>> These are /not/ equivalent. In the former cases, 'f' receives a string
>>> literal as argument, which means that the string is guaranteed to be
>>> zero terminated. In the latter case, 'f' receives an expression (which
>>> can be evaluated at compile time) as argument, so the string may not be
>>> zero terminated. This is a critical difference if 'f' is a (wrapper
>>> around a) C function.
>>
>> You worry too much. With 'f' a wrapper around a C function that takes a
>> const(char)* argument, if the argument is not a literal string then it
>> won't compile. Only string literals are implicitly convertible to
>> const(char)*, not 'string' variables.
>
> You just restated the problem. There needs to be a way to break up
> string literals while still treating them as a single string literal
> that is convertible to 'const(char)*'. You could overload binary '~'
> for this, but I think this may be confusing.
Perhaps I misstated things a bit. Only *compile-time* strings are
implicitly convertible to const(char)*. The expression "abc"~"def" is a
string known at compile-time, and is written in the object file as one
string literal.
Note that compile-time strings could also come from enums and
templates. This will be written as one string literal in the object
file:
enum hello = "hello";
template T(alias s) { enum T = s; }
unittest {
f(hello ~ T!"world");
}
This call to 'f' works because hello~T!"world" forms a compile-time
string and is implicitly convertible to a const(char)*. Try it! Also
try changing 'enum' with 'auto' to make hello a variable and it'll no
longer work.
--
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/
More information about the Digitalmars-d
mailing list