Is implicit string literal concatenation a good thing?

[Bill Baxter]

On Mon, Feb 23, 2009 at 3:42 AM, Don <nospam at nospam.com> wrote:
> Bill Baxter wrote:
>>
>> On Sun, Feb 22, 2009 at 11:12 PM, Denis Koroskin <2korden at gmail.com>
>> wrote:
>>>
>>> On Sun, 22 Feb 2009 16:50:51 +0300, Christopher Wright
>>> <dhasenan at gmail.com>
>>> wrote:
>>>
>>>> Brad Roberts wrote:
>>>>>
>>>>> Back in c and c++, with it's pre-processor, merging adjacent string
>>>>> literals is very handy.  In D, it's only marginally so, but not
>>>>> completely useless.  It can still be used to break a really long string
>>>>> literal into parts.  There's other string boundary tokens in D which
>>>>> might well provide viable alternatives.
>>>>
>>>> In C and C++, there is no way to catenate strings at compile time. The
>>>> only way to catenate strings is with strcat. That places the additional
>>>> burden on programmers that they have to include string.h. For that
>>>> reason,
>>>> it makes sense to catenate adjacent string literals.
>>>>
>>>> In D, there's a compile time catenation operator that doesn't require
>>>> libraries. So the catenation by association saves you only one
>>>> character.
>>>> I'd say that's useless.
>>>
>>> I agree.
>>
>> I use this feature pretty frequently to break up long strings.
>> I think I didn't use ~ for that because it makes me think an
>> allocation might happen when it doesn't need to.
>>
>> But after seeing the discussion here I'd be happy to switch to using
>> "a"~"b" as long as it's guaranteed by the language that such strings
>> will be concatenated at compile time.   (I think the is the case now,
>> right?)
>
> Yes, and because of CTFE, even complicated applications of ~ frequently
> don't involve any allocation. So your intuition was wrong! Implicit
> concatentation was probably one of the things which led to your false
> impression. So it may be bad in that respect, as well as bug-breeding.

Well, like I said, I vaguely recalled that DMD would eliminate the
alloc.  But is it in the spec?  Some other compiler might not
implement that optimization.  Or I might change from "foo"~"bar" to
"foo"~runTimeVar at some point and not notice that I'd introduced an
allocation because of that.  So the benefit of "foo" "bar" there was
that I could be absolutely sure, since it's in the spec, that it
concatenates the strings at compile time.

But I agree it's something that could be gotten rid of.

--bb