Bool alias conversion from core parsers produces unexpected results when writing

[maelgrove]

The current CoreParsers.cs allow converting to boolean values from alias strings like "yes", "true", "1", "no" etc. While this seems quite handy at a first glance, it produces unexpected results when writing a boolean value back, since the ToRawString method of the core parsers might end up converting to a different value since it basically just converts the boolean value to string, without respecting a previous "alias".

So basically if a user prefers to write "1" instead of "true", an application loads a configuration file, sets the value internally to true and saves it back, the resulting file might contain "true" instead of "1". This is unexpected behavior.

Possible solutions would be either take note of the original alias type, or remove the feature completely.

[aloneguid]

Hm from what i remember many years ago it was done because configs were edited by non technical people and we had issues parsing correct values back, this was primary reason.

The issue with remembering original syntax is that value may be written to a store different from where it was read, or it may not exist at all. Hence it's written in the most common form true/false. I guess this may cause issues when configs are shared between applications that expect slightly different syntax, but we had none so far. I find it handy personally not having to answer support calls and let allowances to be made for normal users, rather that throwing exceptions or defaulting to not what's meant to be. I may be wrong .

[maelgrove]

I can definitely understand the intention behind it, but I've got a few other thoughts concerning this based on what I learnt from working in a huge company with primarily non-tech-savvy clients:

• Customers rarely edit e.g. configuration files themselves. First, because they might not even be aware of their existence, second because such people are oftentimes scared of hacking around in files like these.
• Customers do want to 'configure' things though, which is why applications that allow this usually feature some sort of abstraction e.g. a dedicated UI where developers can provide the configuration values in a more meaningful way to the customer.
• If a customer still needs to edit e.g. configuration files, there usually will be (SHOULD BE!) documentation around.
• Boolean values are just one thing. What about lists? Can we always be sure a customer adds an array in the format 'item1,item2,item3', or might they suddenly split lists across multiple lines in a file? Or integer values? Sure it might be obvious something is intended to be an integer, but that doesn't stop anyone from entering floating point numbers. There would be a lot of special cases to cover.
• Can we ensure customers are always consistent? One might prefer to write "1" everywhere, another would maybe add some "yes" every now and then.
• Again, the software might save the configuration in a different manner than it has been originally read. Wouldn't it be confusing to a customer if they write a "yes", and next time they open e.g. the file, there would be a "true"?

[maelgrove]

Closing since possible solution with 'strict' parsing mode.