OK, but definitely don't remove the named methods. I have a use case
where it encumbers code when the names methods don't exist.

Eric Voskuil:
> Hm, I was contemplating standardizing in the other direction (as we have is_valid() methods on all of our bc::chain and bc::message types). I'm not against it though, if you want to add these methods.
>
> I wouldn't ban cast operators as they improve readability / reduce verbosity quite a bit. As a simple example, if you have a type Bool and you want to test the value of a declared Bool named "finished" you would have to say finished.is_true(). I'm not a fan of that, but on the other hand, validity is not what one would necessarily assume when testing objects in general, so .is_valid() can help.
>
> e
>
> -----Original Message-----
> From: Libbitcoin [mailto:libbitcoin-bounces@lists.dyne.org] On Behalf Of Police Terror
> Sent: Friday, September 23, 2016 1:41 AM
> To: libbitcoin@???
> Subject: [Libbitcoin] bool cast operator and equivalent method
>
> There's lots of types in libbitcoin that have a bool cast operator but no corresponding named method. Can I add these?
>
> So for instance, <bitcoin/bitcoin/wallet/ek_token.hpp> defines:
>
> operator const bool() const;
>
> I would add:
>
> bool is_valid() const;
>
> I think every cast operator should have a corresponding named method, and maybe cast operators should perhaps even be avoided because they introduce ambiguity (but that's debatable).
> _______________________________________________
> Libbitcoin mailing list
> Libbitcoin@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/libbitcoin
>