<div dir="ltr"><div class="gmail_extra"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Wed, Jul 22, 2015 at 8:31 PM, Steven D'Aprano <span dir="ltr"><<a href="mailto:steve@pearwood.info" target="_blank">steve@pearwood.info</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Constant-folding 'a' + 'b' to 'ab' is an optimization, it doesn't change<br>
the semantics of the concat. But constant-folding f'{a}' + '{b}' would<br>
change the semantics of the concatenation, because f strings aren't<br>
constants, they only look like them.<br></blockquote><div><br></div><div>It doesn't have to change semantics and it shouldn't. This is a strawman argument. While we could do it wrong, why would we? It's hardly difficult to quote the non-format string while still optimizing the concatenation.</div><div><br></div><div>That is,</div><div><font face="monospace, monospace">    f'{foo}' '{bar}' f'{oof}'</font></div><div>could compile to the same thing as if you wrote:</div><div><span style="font-family:monospace,monospace">    f'{foo}{{bar}}{oof}'</span><br></div><div>the result of something like this:</div><div><font face="monospace, monospace">    COMPILE_TIME_FORMAT_TRANSFORM('{foo}' + COMPILE_TIME_ESCAPE('{bar}') + '{baz'})</font></div><div><br></div><div>This is analogous what happens with mixing raw and non-raw strings:</div><div><font face="monospace, monospace">    r'a\b' 'm\n' r'x\y'</font></div><div>is the same as if you wrote:</div><div><font face="monospace, monospace">    'a\\bm\nx\\y'</font></div><div>or</div><div><font face="monospace, monospace">    r'''a\bm</font></div><div><font face="monospace, monospace">    x\y'''</font></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">In the case of *implicit* concatenation, I think that the concatenations<br>
should occur first, at compile time. Yes, that deliberately introduces a<br>
difference between implicit and explicit concatenation, that's a<br>
feature, not a bug!<br></blockquote><div><br></div><div>Doing the concatenation at compile time does NOT require the "infected" behavior you describe below as noted above. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
I would go further and allow all the f prefixes apart from the first to<br>
be optional. To put it another way, the first f prefix "infects" all the<br>
other string fragments:<br>
<br></blockquote><div>I'd call that a bug. I suppose one person's bug is another person's feature. It violates the principle of least surprise. When I look at a line in isolation and it starts and ends with a quote, I would not expect that to not just be a plain string.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">(Implicit concatenation is a compile-time operation, the format(...)<br>
stuff is run-time, so there is a clear and logical order of operations.)<br></blockquote><div><br></div><div>To you, maybe. To the average developer, I doubt it. I view the compile time evaluation of implicit concatenation as a compiler implementation detail as it makes essentially no difference to the semantics of the program. (Yes, I know that runtime concatenation *might* produce a different string object each time through the code but it doesn't have to. I hope you don't write programs that depend on the presence or absence of string pooling.)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">> And merging f-strings:<br>
> f'{foo}' f'{bar'}<br>
> similarly just becomes concatenating the results of some function calls.<br>
<br>
</span>That's safe to do at compile-time:<br>
<br>
  f'{foo}' f'{bar}'<br>
  f'{foo}{bar}'<br>
<br>
will always be the same. There's no need to delay the concat until after<br>
the formats.</blockquote><div><br></div>Just as it's safe to concat strings after escaping the non-format ones.</div><div class="gmail_quote"><br></div><div class="gmail_quote">There is one additional detail. I think it should be required that each format string stand on its own. That is:</div><div class="gmail_quote"><font face="monospace, monospace">    f'x{foo' f'bar}y'<br class=""></font>should be an error and not the equivalent of</div><div class="gmail_quote"><font face="monospace, monospace">    f'x{foobar}y'<br class=""></font><div><div class="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><font face="arial, helvetica, sans-serif"><br></font></div><div dir="ltr"><font face="arial, helvetica, sans-serif">--- Bruce<br></font><div><font face="arial, helvetica, sans-serif">Check out my new puzzle book: <a href="http://j.mp/ingToConclusions" target="_blank">http://J.mp/ingToConclusions</a></font><br></div><div><font face="arial, helvetica, sans-serif">Get it free here: <a href="http://j.mp/ingToConclusionsFree" target="_blank">http://J.mp/ingToConclusionsFree</a> (available on iOS)</font></div><div><br></div></div></div></div></div></div></div></div></div></div><div> </div></div></div></div>