Length of a const string should be accept as const

[vsfeedback]

The following should be accepted in C#:

const string MyString = "My String";

const int MyStringLength = MyString.Length;

Indeed "MyString.Length" should be optimized to a const anywhere it's used in the code. If the string itself is const, then the length of the string must also be const.

Likewise calls such as "string.IsNullOrWhiteSpace(MyString)" can also be optimized to a const, and from there entire branches of code could potentially be optimized even to the point of being eliminated.

The question might initially arise as to why the developer wouldn't just optimize things like "string.IsNullOrWhiteSpace(MyString)" since it might seem like the developer should already know the const string value. But that isn't actually the case if the const assignment is treated as a configuration value, which might be influenced by compilation flags or otherwise changed for different use-cases/configurations.

This issue has been moved from https://developercommunity.visualstudio.com/content/idea/448694/length-of-a-const-string-should-be-accept-as-const.html
VSTS ticketId: 788854
These are the original issue comments:

Jane Wu [MSFT] on 2/11/2019, 02:59 AM (11 days ago):

Thank you for taking the time to provide your suggestion. We will do some preliminary checks to make sure we can proceed further. We'll provide an update once the issue has been triaged by the product team.

[CyrusNajmabadi]

THe C# language has no knowledge to help inform it of these decisions. And, importantly string.IsNullOrWhiteSpace(MyString) is definitely not a constant. THe docs on it say:

White-space characters are defined by the Unicode standard. The IsNullOrWhiteSpace method interprets any character that returns a value of true when it is passed to the Char.IsWhiteSpace method as a white-space character.

There is nothing that keeps Char.IsWhiteSpace fixed. Nor will it necessarily behave the same on all platforms over time.

The language and/or the compiler cannot optimize this away.

What can potentially optimize this away might be the runtime. It would have the information available at runtime to make this determination.

[kburgoyne]

Agreed re whitespace. I overlooked localization. Still don't see why Length can't be treated as a const. There are several ways in which being able to use constString.Length in a const calculation would help improve readability while not sacrificing efficiency.

const int AllLength = "FirstPart".Length + "SecondPart".Length + "ThirdPart".Length;

is vastly more readable, self-documenting, and less likely to result in errors being introduced in subsequent editing than:

const int AllLength = 28;

or even worse just using "28" in the logic.

Plus .Length of a defined const string provides additional readability and decrease in the likelihood of errors being introduced.

[CyrusNajmabadi]

Still don't see why Length can't be treated as a const.

It can be. But that is better suited as a runtime optimization (which i'm guessing it already does). That way, you get this benefit across all .net languages, not just C#. Could you move this issue over to coreclr for them to track?

There are several ways in which being able to use constString.Length in a const calculation would help improve readability while not sacrificing efficiency.

const int AllLength = "FirstPart".Length + "SecondPart".Length + "ThirdPart".Length;

You coudl just do: static readonly int AllLength = ...

I can't imagine you'd ever find a realistic scenario where that actually caused an efficiency concern.

[CyrusNajmabadi]

Agreed re whitespace. I overlooked localization. Still don't see why Length can't be treated as a const.

By what mechanism would the language know that this value is a constant?

[kburgoyne]

By the same mechanism select other method calls are optimized into inline code. ReferenceEquals(X,null) didn't perform a call. It created an inline comparison.

[kburgoyne]

You coudl just do: static readonly int AllLength = …

Yes, that's what people generally do now. However it does not permit the length to be used in const value calculations.

[CyrusNajmabadi]

However it does not permit the length to be used in const value calculations.

I'm not really seeing a problem. Do you have a real world use case where this substantively affects your performance?

[benaadams]

Runtime side is tracked here: https://github.com/dotnet/coreclr/issues/22511#issuecomment-462220496

[kburgoyne]

It's more an issue of code maintenance reliability and readability. Once a value is forced into a readonly static, it cannot be used in other compile-time calculations.

const string AA = "AA"; const string AB = "AB"; static readonly ALength = AA.Length + AB.Length; const string BA = "BA"; const string BB = "BB"; static readonly BLength = BA.Length + BB.Length; static readonly TotalLength = ALength + BLength; // Error

Now obviously in the real world these wouldn't all be values clustered together. They'd be values coming from different sections of configuration file(s) where they would have been grouped based on their meanings.

Could TotalLength just be the total of all four? Sure. But it's technically code redundancy and an opening for introducing an error during later code editing/maintenance.

Like with object oriented programming, ALength and BLength are meant to encapsulate those values and the intention is TotalLength should not be concerning itself with how those values were derived.

The main goal is one of pursuing code reliability. Particularly over time as edits of the code are performed five years after anyone remembers having written the code being edited.

Why even have const strings? Why not just have static readonly strings? Why have const ints? Why not just have static readonly ints? If there is an argument for having const strings, then the argument carries to the length of a const string being const.

[CyrusNajmabadi]

Once a value is forced into a readonly static, it cannot be used in other compile-time calculations.

Again, i'm not seeing the problem. As i asked before: Do you have a real world use case where this substantively affects your performance?

The main goal is one of pursuing code reliability.

I don't see how a static-readonly is unreliable.

[benaadams]

Attribute arguments?

[kburgoyne]

The pattern I provided in my code example is a pattern I have regularly encountered through my career. The reasons for the pattern occurring is as I explained.

The focus is not on runtime. The focus is on code maintenance over multiple years in an enterprise, and reducing the potential for code modifications to introduce errors.

Again, while this is on a smaller scale, it follows the same concept/justifications as why we use object oriented languages these days.

[CyrusNajmabadi]

The pattern I provided in my code example is a pattern I have regularly encountered through my career. The reasons for the pattern occurring is as I explained.

Then i find your example fairly uncompelling. You can just use static readonly and have all the code maintenance improvements.

The focus is on code maintenance over multiple years in an enterprise, and reducing the potential for code modifications to introduce errors.

I don't see how 'const' makes things any better than static-readonly.

Again, while this is on a smaller scale, it follows the same concept/justifications as why we use object oriented languages these days.

That's an insufficient reason for me. There needs to be an actual super-compelling case to justify the costs of all the work here given that there appears to be a perfectly reasonable thing you can do today in yoru code that gives the benefits you are asking for.

[CyrusNajmabadi]

Specifically:

const int AllLength = "FirstPart".Length + "SecondPart".Length + "ThirdPart".Length;

is vastly more readable, self-documenting, and less likely to result in errors being introduced in subsequent editing than:

You can just write: static readonly AllLength = "FirstPart".Length + "SecondPart".Length + "ThirdPart".Length; It is just as readable, self-documenting, and less likely to result in errors being introduced in subsequent editing.

You can do that today. At zero cost to the language. I recommend taking a peek at https://blogs.msdn.microsoft.com/ericgu/2004/01/12/minus-100-points/. it helps give a perspective on language development. It's not sufficient to just have a language feature. The language feature has to substantively justify its cost.

[kburgoyne]

Then i find your example fairly uncompelling. You can just use static readonly and have all the code maintenance improvements.

False. The pattern I showed cannot be accomplished with only static readonly, and thus cannot provide the sustainability afforded by encapsulation.

To the best of my recollection, although it's been a while, this pattern is possible using other constructs under C++.

I assume the basic conclusion is therefore code sustainability lacks sufficient value.

[CyrusNajmabadi]

False. The pattern I showed cannot be accomplished with only static readonly,

I just showed how you would do that here: #2255 (comment)

and thus cannot provide the sustainability afforded by encapsulation.

I have no idea what this means.

To the best of my recollection, although it's been a while, this pattern is possible using other constructs under C++.

C# isn't C++.

I assume the basic conclusion is therefore code sustainability lacks sufficient value.

Why is 'static readonly' insufficient for code sustainability?

[AmrAlSayed0]

This is already covered by #1028 and #1763 .

[kburgoyne]

@AmrAlSayed0 -- Thanks. I agree now that I see those. This issue should be closed given the @AmrAlSayed0 references.

[svick]

It's more an issue of code maintenance reliability and readability. Once a value is forced into a readonly static, it cannot be used in other compile-time calculations.

const string AA = "AA"; const string AB = "AB"; static readonly ALength = AA.Length + AB.Length; const string BA = "BA"; const string BB = "BB"; static readonly BLength = BA.Length + BB.Length; static readonly TotalLength = ALength + BLength; // Error

That code actually compiles fine (after fixing typos).

[kburgoyne]

I stand corrected. I was overly fixated on compile time and didn't spot it was a construct that would execute at runtime assuming no other optimization.

There is something in patterns we have tried to use in the past which I thought were like the example I gave, but which triggered compiler errors. I will need to investigate those patterns again and see how they varied.

Some of the mistrust of cascading static initializers derives from a historical distrust of static initialization sequencing using some languages. If memory serves, C++ either doesn't or didn't guarantee the sequence of static initialization.

@benaadams comment is still an interesting one, but probably better left to the threads @AmrAlSayed0 referenced.

Apologies for the runaround.

[jnm2]

False. The pattern I showed cannot be accomplished with only static readonly, and thus cannot provide the sustainability afforded by encapsulation.

I can't help but hear Dwight Schrute when reading this paragraph. Thanks for that. :D