Why do bool.TrueString and bool.FalseString exist?

Question

I was reading the MSDN article of the boolean structure, when I saw that a boolean has two fields: TrueString and FalseString. These respectively return "True" and "False".

After some searching, the only example I could find is in this dotnetperls article. The article states:

Programs often need these strings. TrueString and FalseString are a useful pair of readonly members. They represent truth values in string format. They provide indirection and abstraction over directly using string literals.

So appearantly it's useful for some situations. But the same article fails to provide a realistic example (IMHO anyway).

Some further reading also brought this to my attention: TrueString and FalseString are public static readonly fields. And this dornetperls article states:

The language specification recommends using public static readonly fields ... when the field is subject to change in the future.

Now this I can somewhat understand. If the .NET developers ever decide to change "True" and "False" to respectively "OkeyDokey" and "Negatory", it's smart to use TrueString and or FalseString.

But that still leaves me with the question: in what kind of scenario do you want to compare a string with the string literal of a boolean? Because appearantly: "Programs often need" them.

Answer 1

If the program stores data in a human readable file or database, it may need to store values as strings. When you read the data back in, if you know the data was written by your application and uses a standard string representation, you can compare x == bool.TrueString faster than you can bool.TryParse(x ...). You could also validate the data by making sure all values x == bool.TrueString || x == bool.FalseString

If the data was typed by humans, or a different system, TryParse is a better option, as it accepts more values as true and differentiates between a definite false and an invalid input. (MSDN Boolean TryParse)

Answer 2

In easy words. Boolean is a Structure. this boolean expose ToString() method which represent a human readable text for the users. So if you write some thing like.

bool b = false;
b.ToString();

the output will be the "False" insteed of 0. the "False" is readable by human and easyly being captured.

Also some where you may want to parse a text value to a boolean value. so these also can be represented as boolean values. for example. we use

Boolean.TryParse("false" ,out mybool)

the false value is being set by the Tryparse method as this finds that we can read values from strings tool.

Answer 3

It can be used as a default value for missing "stringly-typed" configuration parameters. Here's a concrete example I've recently used:

 if (bool.Parse(ConfigurationManager.AppSettings["IsTestMode"] ?? bool.FalseString)) ...

...which is - in my humble opinion - simpler and more readable than

 var isTestModeString = ConfigurationManager.AppSettings["IsTestMode"];
 if (isTestModeString != null && bool.Parse(isTestModeString)) ...

(I deliberately do not use TryParse here, since I do not want to silently ignore invalid values. I want an exception to be thrown, if the configuration value is present and something other than True or False.)

Answer 4

For the same reason that string.Empty exists. Some people prefer a semantically named value in code over a literal one.

In modern .NET (anything after .NET Framework) the following code prints True three times:

Console.WriteLine(ReferenceEquals("True", bool.TrueString));
Console.WriteLine(ReferenceEquals("False", bool.FalseString));
Console.WriteLine(ReferenceEquals("", string.Empty));

This tells us there is zero runtime difference between the literals and the fields. They are exactly the same object at runtime.

Try this for yourself on sharplab.io here.

---

Others have mentioned using it to compare with when parsing boolean strings, but I would not recommend that. If you want to convert a string to a bool, use bool.TryParse or bool.Parse. Using == does a case-sensitive comparison, which is probably not what you want. Furthermore, the framework's methods are optimised specifically for common cases. You can see these optimisations in the code on GitHub here: https://github.com/dotnet/runtime/blob/f8fa9f6d1554e8db291187dd7b2847162703381e/src/libraries/System.Private.CoreLib/src/System/Boolean.cs#L226