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