Kill implicit joining of adjacent strings

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Mon Nov 29 13:44:48 PST 2010


On 11/29/10 3:38 PM, Bruno Medeiros wrote:
> On 20/11/2010 05:31, Walter Bright wrote:
>> Stewart Gordon wrote:
>>> On 12/11/2010 09:53, Andrei Alexandrescu wrote:
>>> <snip>
>>>> Well put me on board then. Walter, please don't forget to tweak the
>>>> associativity rules: var ~ " literal " ~ " literal " concatenates
>>>> literals first.
>>>
>>> You mean make ~ right-associative? I think this'll break more code
>>> than it fixes.
>>>
>>> But implementing a compiler optimisation so that var ~ ctc ~ ctc is
>>> processed as var ~ (ctc ~ ctc), _in those cases where they're
>>> equivalent_, would be sensible.
>>
>> Andrei's right. This is not about making it right-associative. It is
>> about defining in the language that:
>>
>> ((a ~ b) ~ c)
>>
>> is guaranteed to produce the same result as:
>>
>> (a ~ (b ~ c))
>>
>> Unfortunately, the language cannot make such a guarantee in the face of
>> operator overloading. But it can do it for cases where operator
>> overloading is not in play.
>
> So if you have the code:
> (a ~ b ~ c)
> and b and c are strings, but a is not a string (nor has a toString
> method, nor implicit convertion), but has a overload of the append
> operator, then b and c will not be joined in compile-time, according to
> that?

That is correct. The compiler cannot infer that user-defined ~ is in 
fact associative.

Andrei


More information about the Digitalmars-d mailing list