[stiff]

The size has to be known at compile time, though. One can do a slice of slices, but then it's not necessarily continuous in memory. So you are left with allocating a one dimensional array of size x*y and doing index calculations by hand like in the good old 70's or something.

[a-nom-a-ly]

(Can't reply to your post below)

> I edited that part of the comment out because it was not really related to anything, but I meant that all identifiers go into a single namespace, e.g if you have a package called bytes you can't call a variable bytes, if you have a struct type called bytes, you can't call the instance bytes

http://play.golang.org/p/98vt2YLslY

[stiff]

I got confused about the details, but this does hit me, the example I had in mind is this:

  package main

  import (
  	"container/list"
	"fmt"
  )

  func main() {
  	list := list.New()
  	list.PushBack(10)
  	list2 := list.New()
  	list2.PushBack(10)
  	fmt.Println(list)
  	fmt.Println(list2)
  }

This does not compile, list variable shadows the list package. I would much prefer doing list::New() for package access like in C++, and being free to use obvious variable names (all the time the most obvious variable name is also the name of the package).

[a-nom-a-ly]

Adding `::` just to separate package namespace adds nothing useful IMO; just more noise and one more needless concept.

If I decided to re-use the package name more than once it'd be `list1, list2`

I guess it's probably a programming culture thing, but I wouldn't use the word `list` to begin with. I'd use `l1`, `l2` etc. in the case where the name isn't important. It conveys no less information than `list` and short variable names AFAIK are already idiomatic so it's not even unconventional... But with all that said, `list2` wasn't a very good variable name to begin with. If you needed more than one list, then they clearly served different purposes and in that case it makes sense to name them as such: `apples`, `oranges`, `input`, `output`.

[stiff]

It's an example, not a real program, I do like however to call my variables "file", "path", "buffer" instad of having "f", "p" and "b" or "buf", especially when there is a lot going on in the algorithm. I don't think there is a lot of baggage in having a separate namespace for packages and being able to say:

file = File:open("file")

[laumars]

You can alias imports, Eg

    import (
        cont_list "container/list"
    )

    func main() {
        list := cont_list.New()
    }

[microtonal]

(Can't reply to your post below)

Hint: wait a few minutes, it's the cool-off period. Replying to the parent breaks threading and makes it annoying to read discussions ;).

[mseepgood]

> The size has to be known at compile time, though.

That's the whole point of an array in Go. So you meant slices, not arrays.

[banachtarski]

To be fair, C++ doesn't have dynamic statically sized arrays yet either although you can get close with constexpr (but still done at compile time) yet.

Dynarray was slated for C++14 but has been pushed since it really isn't that useful and most people can get away with using vector.

[howeman]

Packages aren't enough of a namespace differentiator for you?

[stiff]

I edited that part of the comment out because it was not really related to anything, but I meant that all identifiers go into a single (language-level, not program-level) namespace, e.g if you have a struct type called Bytes, you can't call the instance Bytes etc. I end up having to use a lot of ugly variable names.