Raw string new line enforcer #6800

NN--- · 2022-12-14T16:00:03Z

NN---
Dec 14, 2022

Raw string doesn’t allow setting the exact newline character.
This makes it harder to use it when anyone checks out code with automatic LF->CRLF conversion.

My suggestions is to add a feature making it clear.
(The actual syntax can be different)

Sample:

var a = LF”””
This has LF line ending
“””;

var b = CRLF”””
This has CRLF line ending
“””;

HaloFour · 2022-12-14T16:20:48Z

HaloFour
Dec 14, 2022

See:

#4304 (comment)

Verbatim and raw strings both do not process the characters within the literal (aside the escaping of double-quotes in the former). It's intentional that whatever newline character(s) are in the source file end up in the literal. It's been suggested to not use such tools as "autocrlf", honestly I don't think I've met an editor in Windows lately that doesn't understand just \n.

0 replies

CyrusNajmabadi · 2022-12-14T16:22:11Z

CyrusNajmabadi
Dec 14, 2022
Collaborator

This makes it harder to use it when anyone checks out code with automatic LF->CRLF conversion.

That appears to be an issue with your source control system. It would affect normal strings as well. I would recommend not having other tools munge your source files.

9 replies

CyrusNajmabadi Dec 14, 2022
Collaborator

There are many posts on what to do here when managing a repo. For example: https://stackoverflow.com/questions/2517190/how-do-i-force-git-to-use-lf-instead-of-crlf-under-windows

Bonus, this works for all files, not just a portion of c# files.

CyrusNajmabadi Dec 14, 2022
Collaborator

As well, it doesn't solve the problem where I want all source files to be LF while one string to be CRLF, for instance HTTP requires this line ending.

You can have exceptions for your gitattributes.

That said, if you need that precise level of control, I would honestly just use a normal string there.

It still has many bureaucracy steps to add such enforcements.

I don't see the problem with that. So the steps once, and now you're good... :-)

NN--- Dec 14, 2022
Author

I don't think the real world issue is fully understandable here.
I do agree that there are solutions and enforcements for this.
It is also possible to perform validation during the build.

However it any of these don't solve the problem in one minute.

My situation (and it is not in only one repository and I don't have ownership on the whole repository, only on few files there) is the following:

Many files with different owners residing over the globe indifferent teams.
Many files with different line endings, some LF, some CRLF, some mixed.

Adding gitattributes or editorconfig won't fix the existing files line ending,
Changing line ending means a big pull request requiring more people to approve.
It can be done as a future big step.

Having a feature with explicit line ending would make it possible to create the smallest change that possible for a particular need.

I can use a regular string of course and this what I do now due to impossibility of putting an explicit line ending in raw string.

Thanks :)

HaloFour Dec 14, 2022

This is an option:

var html = """
           <html>
           </html>
           """.ReplaceLineEndings("\r\n");

NN--- Dec 16, 2022
Author

This involves unnecessary runtime overhead.

hexawyz · 2025-02-05T10:26:28Z

hexawyz
Feb 5, 2025

Besides git source control issues, that can painfully be worked around, I believe there is a problem when the same bit of code is going to generate a different result depending on when and how the code is built.
IIRC, this had been recognized to be a problem to provide an option that would change the language semantics in the case of the checked compiler option, and we are quite close in this scenario, although the option is not controlled by the compiler. (Which in some ways is even worse)

You can imagine someone copying code from the web and pasting it in their code editor of choice, and having the code behave differently on their machine, without it being explicitly obvious, as the encoding of line endings is invisible to our eyes.
Admittedly, we generally don't care about which line endings are used, as long as they are in the format generally expected by the environment, so the current default will be fine is most cases.

However, there are very specific scenarios in which this can be a problem, and I firmly believe that the developer should be able to explicitly enforce how his code is to be interpreted, so that the results can be guaranteed irrespective to the external circumstances.

Example of such a scenario: A unit test is built on a windows machine using crlf line endings and run on a linux machine using lf line endings, and the test fails.

It is in fact very weird that the compiler would have a specific interpretation of what is a line ending (if only for counting them and delimiting #directives), but would stop having that interpretation when entering a string…
Which it doesn't, of course, because line numbers are still counted, and raw string litterals support de-indentation of lines.

Verbatim and raw strings both do not process the characters within the literal (aside the escaping of double-quotes in the former)

See the above, I believe that de-indentation already counts as processing. It wouldn't be unreasonable to allow an optional mode that would provide a strict interpretation of line endings.

Proposal

Regarding the proposal here, I would have proposed to put the specifier as a suffix, as I tend to believe that it makes the syntax simpler and avoids introducing a keyword that would have a wide scope.
We already have u8 suffixes for string litterals, so I'd propose we should extend this mechanism to have the following suffixes for verbatim and raw string litterals:

none: The current default, using file line endings
u8: UTF-8 string literal using the current defaults
crlf: Line endings that are part of the string litteral will be converted to CRLF sequences
lf: Line endings that are part of the string litteral will be converted to LF sequences
u8crlf: UTF-8 string literal whose string endings will be converted to CRLF sequences
u8lf: UTF-8 string literal whose string endings will be converted to LF sequences

Generally, the rule if we ever need to have other specifiers similar to u8, should be to have crlf or lf always be the suffix.

Example

var s = """
    Hello
    World
    """u8lf;
Assert(s.Length == 11);

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Raw string new line enforcer #6800

{{title}}

Replies: 3 comments 9 replies

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

Select a reply

Raw string new line enforcer #6800

NN--- Dec 14, 2022

Replies: 3 comments · 9 replies

HaloFour Dec 14, 2022

CyrusNajmabadi Dec 14, 2022 Collaborator

CyrusNajmabadi Dec 14, 2022 Collaborator

CyrusNajmabadi Dec 14, 2022 Collaborator

NN--- Dec 14, 2022 Author

HaloFour Dec 14, 2022

NN--- Dec 16, 2022 Author

hexawyz Feb 5, 2025

Proposal

Example

NN---
Dec 14, 2022

Replies: 3 comments 9 replies

HaloFour
Dec 14, 2022

CyrusNajmabadi
Dec 14, 2022
Collaborator

CyrusNajmabadi Dec 14, 2022
Collaborator

CyrusNajmabadi Dec 14, 2022
Collaborator

NN--- Dec 14, 2022
Author

NN--- Dec 16, 2022
Author

hexawyz
Feb 5, 2025