-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement string block literals. #11975
Conversation
Raw string in the code example is only needed for \n; everything else is fine with normal strings as well. In particular: ", "" or """ won't cause any trouble. Any indentation within the string block becomes part of the string. Indentation of the block itself (two spaces extra to the ": line) is not included. |
not giving +1 or -1 but note: triple quotes can represent any string (that does not contain a triple quote strictly inside; at the boundaries is actually ok); this would need to be the case here as well.
str = (":
formatted
) should produce
|
@timotheecour In raw/proc I concur that the missing final endline is an important enough special case to deserve some thought. By adding that feature the I believe that the normal case for a multi-line literal is to output multiple lines, all terminated by newline (as per standard text file formatting). Thus, it cannot be the default to omit the final newline, as adding it manually would then be ugly and easily accidentally missed. In normal mode (which may also be combined with fmt by The question remains whether this can be solved in raw mode in a sensible manner, and if suitable, also extended to normal mode (there should be no surprising differences between the modes). A related issue irking me is the one with cr-lf newlines, seen in most Internet protocols, that usually have to be mixed with lf-endlined text or binary data (HTTP, Redis), as adding In essence, if one could mark a source line as adding to the string either no newline, CR-LF, or (the default) LF, all these problems would be solved. The first question is whether this should be a library function alike Adding similar modes to the start tag (e.g. after the colon) would be easy and has the benefit that it can apply exclusively to source code line breaks, leaving any escaped newlines untouched and not affecting the use of fmt. Another option that comes to mind, is supplying out-of-band control codes in the left margin of the string block, like so:
This is the most powerful solution and it still keeps everything verbatim in the content, yet may well be seen ugly and is certainly not intuitively clear in meaning. It is debatable whether mode changes should stick, i.e. would Whether adding any such special syntax to address a border nuisance is justified, is an open question I cannot answer. Perhaps you can think of something else? |
This pull request has been automatically marked as stale because it has not had recent activity. If you think it is still a valid PR, please rebase it on the latest devel; otherwise it will be closed. Thank you for your contributions. |
let str = ": formatted text is possible echo str echo( r": def foo(): """Generated Python function without any escaping""" print("".join(["foo", "bar"])) print("Hello\nWorld!") ) echo ": <pre>\ lines split only in source code, \ no newlines in output\ </pre>\
Rebased on top of current nim-lang/devel branch. |
Discussion in nim-lang/RFCs#161