I have (schematically) seen this C++ code in production:
bool flag = "false";
This kind of problem is introduced by implicit type conversions, and
(outside of some carefully controlled cases with interfaces), Go does not
have them, for just this sort of reason. Bugs caused by implicit type
conversions can be very hard to see.
-rob
On Sun, May 21, 2017 at 1:30 AM, Jakob Borg <ja...@kastelo.net> wrote:
> On 20 May 2017, at 17:01, bcandler100 via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
> >
> > And I wonder why the language designers decided not to allow this:
> >
> > if err {
> > ...
> > }
> >
> > especially since Go has a well-defined notion of "zero value" which
> could be treated as "false" in this context.
>
> Implicit type conversion is necessarily a thing in dynamically typed
> languages. Having empty dicts and so on be false can be convenient but also
> confusing. I assume you mean that a nil slice in Go would false, for
> example. Would the empty slice also be false? A zero length slice? A slice
> containing only zero values? A zero sync.Mutex or bytes.Buffer? Those are
> both usable in their zero state and having them be false would enable some
> really confusing antipatterns. I don't think we'd have to wait long for the
> first
>
> If !mut {
> mut.Lock()
> }
>
> to appear, for example.
>
> //jb
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
