5 ms·

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.

• sacado2 8y ago
  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.
  • speps 8y ago
    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 https://www.destroyallsoftware.com/talks/wat
    • sacado2 8y ago
      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.
  • coldtea 8y ago
    >Who does `true := false` in actual code, though? Anybody who is still human and can do a typo.
    • sacado2 8y ago
      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.
      • coldtea 8y ago
        >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 { // ... }
        • sacado2 8y ago
          > 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 { ... } }
      • SamWhited 8y ago
        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.
  • jonbodner 8y ago
    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.
    • sacado2 8y ago
      I'm with you there, I have to admit I already did the true := false trick for the amusement and bewilderment of my colleagues.
• Groxx 8y ago
  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".
• krylon 8y ago
  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.
• hajile 8y ago
  JS used to do something similar with being able to redefine undefined.
• cdoxsey 8y ago
  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-264921280 https://github.com/golang/go/issues/18193#issuecomment-26492...