<div style="font-family: arial, helvetica, sans-serif; font-size: 10pt"><div dir="ltr">On Sun, Dec 2, 2012 at 1:20 AM, Daniel Jasper <span dir="ltr"><<a href="mailto:djasper@google.com" target="_blank">djasper@google.com</a>></span> wrote:<br>
<div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Fri, Nov 30, 2012 at 11:50 AM, Douglas Gregor <<a href="mailto:dgregor@apple.com">dgregor@apple.com</a>> wrote:>> +/// \brief A character range of source code.<br>
</div><div class="im">
>> +struct CodeRange {<br>
>> +  CodeRange(unsigned Offset, unsigned Length)<br>
>> +    : Offset(Offset), Length(Length) {}<br>
>> +<br>
>> +  unsigned Offset;<br>
>> +  unsigned Length;<br>
>> +};<br>
>><br>
>> Why isn't this a SourceRange or CharSourceRange?<br>
><br>
><br>
> This would put the burden on the client to do the "Offset+Length -><br>
> SourceRange" translation. But you're right, in this case that might be the<br>
> right trade-off…<br>
><br>
><br>
> This seems like a *very* small burden to eliminate two<br>
> similar-but-not-the-same concepts with disturbingly similar names. It's<br>
> CharSourceRange you want, though.<br>
<br>
</div>Ok, I will remove CodeRange here. The reasoning behind it was that<br>
both SourceRange and CharSourceRange effectively work with<br>
SourceLocations and SourceLocations provide locations based on a<br>
SourceManager. We thought that the library might have users that do<br>
not actually have a SourceManager...</blockquote><div><br></div><div style>By the way - I still expect that we'll need a SourceManager independent representation of code ranges, but the current interface is obviously not SourceManager independent - it even takes a SourceManager and works exactly on one file, so it doesn't make sense to artificially decouple this one piece.</div>
<div style><br></div><div style>Cheers,</div><div style>/Manuel </div></div></div></div></div>