<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 10, 2015, at 11:07 PM, Travis Tilley <<a href="mailto:ttilley@gmail.com" class="">ttilley@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_default" style="font-family:verdana,sans-serif">Chris - due to the complexity involved, would it make sense to have multiple proposals? One syntax need not fulfill the needs of every use case. </div></div></div></blockquote><div><br class=""></div><div>I’m not sure how to interpret this question. Are you asking whether a proposal should start out simple, then have new things piled on top of it? Or are you suggesting it would be better to have multiple new language features solving different problems?</div><div><br class=""></div><div>In this case, my personal preference is to have a really well thought out long term vision for what we are doing in this space, and then subset the implementation to start with the simple pieces. This avoids painting ourselves into a corner. Further, I really hope we can avoid adding N new string literal syntaxes. I see the existing one as the “simple” case, and the multiline case as the “advanced” case which can have knobs put on it for other advanced uses.</div><div><br class=""></div><div>-Chris</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_default" style="font-family:verdana,sans-serif">My immediate and personal concern is the simplest possible syntax for multi-line string literals with no behavioral differences from normal string literals other than 1) the ability to span multiple lines and 2) the ability to contain unescaped quotes as long as they are not triple quotes. As additional features, the potential indentation handling previously discussed in this thread would be a massive bonus that'd make life easier.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br class=""></div><div class="gmail_default" style="font-family:verdana,sans-serif">Additional proposals for full-on heredoc syntax with both indentation aware and ignoring syntax (as is typical in other languages) could be made and implemented separately.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br class=""></div><div class="gmail_default" style="font-family:verdana,sans-serif">I have no use for an escape-ignoring/escape-unrequiring syntax and would have to leave that up to others to flesh out and/or implement. This would make most sense with a heredoc style syntax where the terminator is a very specific string.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br class=""></div><div class="gmail_default" style="font-family:verdana,sans-serif">I also have no use for specifying a dialect for a string, which Jordan Rose suggests is useful for shaders, and have no idea how to implement such a feature.</div><div class="gmail_extra">
</div></div>
</div></blockquote></div><br class=""></body></html>