> It's about strong typing. I detest stringly-typed programming. I feel like that's something that's more an appropriate concern for the application, and not s

> It's about strong typing. I detest stringly-typed programming. I feel like that's something that's more an appropriate concern for the application, and not something that ought to be baked into the configuration format itself. For example: > E.g.: a guid turns up as a "System.Guid" type in C# instead of "System.String". Can you not just pass the System.String you get from the decoder into System.Guid's constructor and handle the resulting error should that string not actually be a GUID? Like, my problem with a lot of config file formats is that they're frequently too clever about assuming types of things when I would much rather they be strings by default for me to interpret later. > If you roll your own ["hex-string-to-byte-array" decoding function], it'll be about 10x less efficient than something done properly using SIMD instructions. Unless you roll your own that uses those SIMD instructions, whether in hand-written assembly or in a programming language with a compiler smart enough to use SIMD for this. This does, however, reek of a premature optimization.