1. 6
  1.  

  2. 1

    So how does one convert a string to MyString?

    1. 1

      With type conversion. Here is their example fixed to work: http://play.golang.org/p/de-6a0bK1w

      Note that conversion is different than type assertion. Conversion changes the expression to the type: http://golang.org/ref/spec#Conversions

      Assertion says the type has an interface: http://golang.org/ref/spec#Type_assertions

      These are easy to get mixed up because of the syntax: string(foo) vs foo.(string)

      1. 1

        And do you know why it was decided to add this ‘untyped constant’ idea rather than just say a constant is of a type and one has to use type conversion to force it into their type?

        1. 2

          I suspect this is confusing because your thinking constants are variables defined with const. A constant is any literal value in the application. So even if you say something like:

          var s string = "foo"
          

          You’ve just assigned the constant string literal “foo” to the variable s.

          The reason for this is go is very simple and transparent with how memory is managed. When you have a string literal “foo” in your code, that string literal exists in the program code that is loaded into memory. You can take the address of it, but you can’t modify it because application code can’t be modified. It’s not part of the stack/heap where variables are created.

          Getting back to untyped constants… what go is doing is what it’s not doing. It’s not adding a type label to that string literal. The literal exists as a pure string representation. Go determines a default type for it by examining it’s syntax.

          When you say:

          const foo = "foo"
          

          Your saying, store this string literal and give it a label so I can refer to it.

          When you say:

          const foo string = "string"
          

          Your saying, store this string literal with a label and also specify it’s type as being a string.

          I’m probably off on the exact memory representations going on, but that’s the gist of it.

          1. 1

            I am asking why was it decided that I can do var s MyString = "foo" rather than saying that "foo" is always a string and one must always perform a type conversion, so var s MyString = MyString("foo")

            1. 2

              I dunno the why and I’ll refrain from guessing, but all the rules are here if you’re interested: http://golang.org/ref/spec#Properties_of_types_and_values

              1. 1

                Seems like it’s more for ints than for typedef’d strings. With your proposal:

                var x int = 1 // ok
                var y uint = 1 // bad
                var z uint = uint(1) // ok, but ugly
                

                With go’s behavior:

                var x int = 1 // ok
                var y uint = 1 // ok, because the constant 1 *could be* of type uint
                var z uint = uint(1) // unnecessary, but ok
                
                1. 2

                  However most people would probably just write:

                  var z = uint(1)
                  

                  Right?

                  1. 1

                    Most of the time you write:

                     z := 1
                    

                    No var needed. The : specifies a new variable and sets the type automatically. I’d recommend walking through the go tour: http://tour.golang.org/#1