djasper added a comment.

Thinking about this some more, starting to merge deletions now, but only some 
of them is a bit suspect. I think we either want to allow even more or continue 
to be restrictive for now.

I think fundamentally, there are two questions that we need to answer:

1. Is this something that the user/tool author would likely want to do?
2. Is add the replacement order-dependent in any way?

I have no clue about #1, I'd have to see use cases. E.g. what use case are you 
trying to solve here?

But lets look at #2: I think I have come up with an easy definition of what 
makes something order-dependent. Lets assume we have two replacements A and B 
that both refer to the same original code (I am using A and B as single 
replacements or as sets of a single replacement for simplicity). The question 
is whether A.add(B) is order-dependent. I think we should define this as 
(assuming we have a function that shifts a replacement by another replacement 
like your getReplacementInChangedCode from

A.add(B) is order-dependent (and thus should conflict, if 
A.merge(getReplacementInChangedCode(B)) != 

I think, this enables exactly the kinds of additions that we have so far 
enabled, which seems good. It also enables overlapping deletions, e.g. deleting 
range [0-2] and [1-3] will result in deleting [0-3], not matter in which order.

cfe-commits mailing list

Reply via email to