Eric Newton

**Comment by [ohadschn](https://github.com/ohadschn)** _Thursday Nov 02, 2017 at 19:43 GMT_ ---- +1 from me. If I have to do my own validation, not only do I need to write code...

So realistically, this is a parsing library and all the validation is around successful parsing of strings to numbers etc. [FileExists], [DirectoryExists], [NetworkServerReachable], [AmazonServiceHasItem] and similar, would definitely be out-of-scope...

You almost need to return ParserResult from that instead, so you won't have a null return that you'll have to guard against. Next, I'd have a ValidateOptions method that would...

@tmillican I am of the same mind on this topic. There's definitely a difference between specifying an invalid file and having a filename parsed into the wrong variable. Syntax vs...

The enhancement could allow for "pre-options-summary-text" and "post-options-summary-text" blocks

The core code of the parser is only looking for "OptionsAttribute" not "LogFileOptionAttribute" types... Submit a pull request with some initial work to enable this feature and we would consider...

Very True. We could probably add an additional property on the OptionAttribute would work. Or a ParsingOptions property for specifying DateTime(Offset) conversion handling. ``` public class MyOptions { [Option("d", DateTimeParsing=DateTimeParsing.Utc]...

A lot of build errors in the test project related to this change. Can we clean those up?

Why would this throw an error? You have `required = false` in the Option attribute... theres a third scenario: ``` cli --value cli --value blah cli --value --othervalue ``` Effectively...

maybe things in the release notes can update that fact? I almost just moved on when I saw version xxx for Angular 1.3x is latest version.