3 ms·

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 allocat

• howeman 13y ago
  Packages aren't enough of a namespace differentiator for you?
  • stiff 13y ago
    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.
• a-nom-a-ly 13y ago
  (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 http://play.golang.org/p/98vt2YLslY
  • stiff 13y ago
    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 13y ago
      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 13y ago
        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 13y ago
      You can alias imports, Eg import ( cont_list "container/list" ) func main() { list := cont_list.New() }
  • danieldk 13y ago
    (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 ;).
• banachtarski 13y ago
  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.
• mseepgood 13y ago
  > 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.