<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Jun 27, 2012, at 9:37 AM, Jordan Rose wrote:</div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Jun 27, 2012, at 9:33 , Dmitri Gribenko <<a href="mailto:gribozavr@gmail.com">gribozavr@gmail.com</a>> wrote:</div><div><br></div><blockquote type="cite" style="font-family: monospace; ">Why not StringRefs?<br></blockquote><br style="font-family: monospace; "><span style="font-family: monospace; ">Per Doug's comment:</span><br style="font-family: monospace; "><br><blockquote type="cite" style="font-family: monospace; ">+ /// Contains text value associated with a token.<br>+ StringRef TextValue1;<br>+<br>+ /// Contains text value associated with a token.<br>+ StringRef TextValue2;<br><br>It would be nice if Token were a POD type. Could we just store ptr/length for TextValue1 and TextValue2, so that Token remains a POD?</blockquote><div><br></div><div>Oops, I forgot that SourceLocation is POD (of course). Never mind.</div></div></div></blockquote><div><br></div>Wait, what? In what sense is StringRef not POD when SourceLocation is? Neither is technically POD, because they both have a non-trivial default constructor. However, both are trivially copyable and standard layout.</div><div><br></div><div>John.</div></body></html>