There are some bc::wallet consistency issues (is_valid() vs. bool(), special treatment for bc mainnet and testnet), and internal redundancies (both is_stealth() and is_payment() could be replaced by just the former, is_mainnet() and is_testnet() are made redundant by version()). Once these are removed the class reduces to:

> address_validator(const std::string&)
> operator bool() const
> bool is_stealth() const
> uint8_t version() const

Given that the class does not expose the actual addresses one must eventually re-parse the string. This means the string will always be parsed 2-3 times.

Proper implementation would also require that the result of the last parse be tested for validity (and intended version). One could avoid this by caching a copy of the originally-tested string and its state.

Given that the semantics of payment_address and stealth_address are entirely different (one does not pay to a stealth address, one pays to a payment_address generated from the stealth address) I don't see any advantage to a libbitcoin class/utility to generalize the text parsing. It will be just as complex to use this class (more so in some cases) than to simply use fall-back parsing.

FWIW The application could us a simple string length test to determine whether the text field could be a valid payment address vs. stealth. This eliminates any need for fall-back parsing, resulting in a simple/unconditional code path (and a single parse per entry).

e

> On Jan 2, 2017, at 3:42 AM, Police Terror <PoliceTerror@???> wrote:
>
> Proposed class would have these methods:
>
> address_validator(string)
>
> is_valid()
> is_mainnet()
> is_testnet()
> is_payment()
> is_stealth()
>
> uint8_t version()
>
> address_validator_type type()
>
> Does that sound better?
> _______________________________________________
> Libbitcoin mailing list
> Libbitcoin@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/libbitcoin