You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Option class can currently be instantiated as follows. (Argument is similar so for the purpose of this issue, I'll only talk about Option, but the change would apply to both.)
This capability wasn't removed because of scenarios where parsers might be built based on a runtime reflection-dependent model, such as attribute-based app models. Forcing use of the generic types was potentially awkward here. As source generation has become more common and as we look to make the library more performant, the use case has become less compelling and the performance and complexity cost less worthwhile.
They are still needed though as base type, e.g. for the Command.Options collection.
The text was updated successfully, but these errors were encountered:
jonsequitur
changed the title
Consider removing non-generic Argument and Option classesArgument and Option classes: consider making them abstract or removing them
Feb 12, 2022
jonsequitur
changed the title
Argument and Option classes: consider making them abstract or removing them
Consider making Argument and Option classes abstract
Feb 12, 2022
The
Option
class can currently be instantiated as follows. (Argument
is similar so for the purpose of this issue, I'll only talk aboutOption
, but the change would apply to both.)By default, the
ValueType
forOption
isstring
.This is largely equivalent to instantiating an
Option<int>
, and the following will return anint
(as a compile-timeobject
):The non-generic
Option
can also be late-bound like this:This capability wasn't removed because of scenarios where parsers might be built based on a runtime reflection-dependent model, such as attribute-based app models. Forcing use of the generic types was potentially awkward here. As source generation has become more common and as we look to make the library more performant, the use case has become less compelling and the performance and complexity cost less worthwhile.
They are still needed though as base type, e.g. for the
Command.Options
collection.The text was updated successfully, but these errors were encountered: