Hacker News Reader

Comment by speps | Hacker News Reader

WAT 16 is the most shocking really. Reminds me of Python 2 where True and False can be overridden as well, it was fixed in Python 3.

View on HN

This was a design chose to minimize the number of keywords in the language.

> The rationale is pretty simple: Only identifiers that must be keywords for syntactic reasons are keywords.

> In fact, in the very beginning there was some discussion as to whether things like nil, iota, etc. should be keywords. Eventually we agreed on the rule above which settled it.

https://github.com/golang/go/issues/18193#issuecomment-26492...

On the one hand, I find it revolting that the language will let me do that.

On the other hand, why would I ever want to do that? It's not something one might do by accident. It's along the line of C letting you say

    idx[arr]

instead of

    arr[idx]

It's unfortunate that it is possible, but there is no good reason to ever do this unless one is trying to confuse one's enemies.

Who does `true := false` in actual code, though? However, in real life, I've already wondered if using `new` as a variable is bad practice or not:

    old := x
    new := foo(&x)
    if old != new {
       return &Bar{} // oops, return new(Bar) won't compile
    }

That should at least be caught by linters.

WATs are usually never real code, some of the ones in there are but I would encourage you to look at the linked video in the article for a fun look at other languages WATs: https://www.destroyallsoftware.com/talks/wat

Some of those in the original presentation can actually happen accidentally because of dynamic typing, though. For example, you could get a value from a JSON object, expect it to be a number, but have objects instead, and perform a {} + {} without actually knowing it, have the interpreter execute it with no error, and wonder where in your code you caught that NaN value (because it would propagate all along).

OTOH, it's very unlikely you type accidentally `true := x` in your code, and even if you did, that would very probably be caught by the compiler anyway.

>Who does `true := false` in actual code, though?

Anybody who is still human and can do a typo.

What typo can that be though? If you wanted to do `if true == x` and typed `if true := x`, the compiler will tell you. If you mistyped your variable name, and wanted to do `tue := false` for instance, but inadvertantly typed `true := false`, the compiler will tell you "true declared and not used". I can't really find a compelling example.

>If you mistyped your variable name, and wanted to do `tue := false` for instance, but inadvertantly typed `true := false`

You don't need to have a variable like "tue" to make such a typo. Since your writing an if statement, you already have "true" and "false" in mind, so you just need to be a little absentminded and voila, instead of foo := false you've written true := false. Plus, lots of naive editors will offer to autocomplete something starting with t to true (if they find the token true used elsewhere within the file).

>the compiler will tell you "true declared and not used".

Only if you don't use it. But a few lines below you could very well be using true legitimately too, in which case it wont tell you:

  true := false
  
  ...

  if condition == true {
    // ...
  }

> Only if you don't use it. But a few lines below you could very well be using true legitimately too, in which case it wont tell you:

Good point!

Edit: but then, your expected original variable name, `tue` in my example, would be used while not yet defined:

    true := false
    if foo() || bar {
       tue = true  // Compilation error
    }
    ...
    if condition() == true {
       ...
    }

Only possible case I can think of: you already defined tue, but tried to redefine it via variable shadowing:

    tue := true
    ...
    if cond() {
        true := false
        if foo() || bar() {
           tue = true // Will compile, but not the tue you expected
        }
        ...
        if condition == true {
           ...
        }
    }

The "it's 3AM and I want to write 'myvar := true' and am thinking about 'true' so I write 'true := true' and move on and don't notice" typo.

I chose true := false for the humor and shock value.

As you point out, accidentally redefining the meaning of len or new or close is far more likely.

I'm with you there, I have to admit I already did the true := false trick for the amusement and bewilderment of my colleagues.

JS used to do something similar with being able to redefine undefined.

tbh I think it's a lot less of an issue. It's creating a new var named `true` (or `false`) - that only exists in the scope it's declared in, not globally.

I think it's crazy that this isn't a compile-time error, but it's not even close to "you can change the global value of builtin values".

Reply on news.ycombinator.com