Declarations at file block scope

[beevik]

Top-level declarations are, of course, defined at package block scope, and that's a great default behavior.  I often, however, run into cases where it would be handy to declare identifiers at file scope (similar to the way static variables and functions are scoped in C/C++).  For example, in a package with multiple X_test.go files, I commonly find myself wanting to reuse identifiers for file-specific type declarations (type test struct) and associated variable declarations (var tests []test).  But because all top level declarations have package scope, I have to be slightly more verbose and come up with unique, longer names for the identifiers. Having to do this is not the end of the world, but it is an inconvenience, especially since I often find concise code to be more expressive.

Were file-scoped declarations ever considered for go?  And if so, what were the reasons they weren't included?  Use cases not considered important?  Added complexity?  No elegant convention for declaring them?  Just curious.

[Dave Cheney]

On Wed, Jan 1, 2014 at 8:02 AM, beevik <br...@beevik.com> wrote:

Top-level declarations are, of course, defined at package block scope, and that's a great default behavior.  I often, however, run into cases where it would be handy to declare identifiers at file scope (similar to the way static variables and functions are scoped in C/C++).  For example, in a package with multiple X_test.go files, I commonly find myself wanting to reuse identifiers for file-specific type declarations (type test struct) and associated variable declarations (var tests []test).  But because all top level declarations have package scope, I have to be slightly more verbose and come up with unique, longer names for the identifiers. Having to do this is not the end of the world, but it is an inconvenience, especially since I often find concise code to be more expressive.

Were file-scoped declarations ever considered for go?

No

 

 And if so, what were the reasons they weren't included?  

Simplicity

 

Use cases not considered important?  

Maybe, but simplicity is more important

 

Added complexity?  No elegant convention for declaring them?  Just curious.

func TestFoo(t *testing.T) {

    type fooTests struct {

         a, b int

    }

    tests := []fooTests {

          { 1, 2 },

          { -1, 42 },

    }

    for _, tt := range tests { 

       ...

   }

}

or just skip naming the type altogether, which is a common pattern when writing table driven tests.

http://dave.cheney.net/2013/06/09/writing-table-driven-tests-in-go

Cheers

Dave

 

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Ian Lance Taylor]

On Tue, Dec 31, 2013 at 1:30 PM, Dave Cheney <da...@cheney.net> wrote:
>
>
>
> On Wed, Jan 1, 2014 at 8:02 AM, beevik <br...@beevik.com> wrote:
>>
>> Top-level declarations are, of course, defined at package block scope, and
>> that's a great default behavior. I often, however, run into cases where it
>> would be handy to declare identifiers at file scope (similar to the way
>> static variables and functions are scoped in C/C++). For example, in a
>> package with multiple X_test.go files, I commonly find myself wanting to
>> reuse identifiers for file-specific type declarations (type test struct) and
>> associated variable declarations (var tests []test). But because all top
>> level declarations have package scope, I have to be slightly more verbose
>> and come up with unique, longer names for the identifiers. Having to do this
>> is not the end of the world, but it is an inconvenience, especially since I
>> often find concise code to be more expressive.
>>
>> Were file-scoped declarations ever considered for go?
>
>
> No

Just FYI, we actually did have file-scope declarations for a while
before the public announcement of Go. In the very early days each
file of a package was compiled separately, and the resulting object
files were assembled into an archive for the package. You can still
see this approach in a few relics here and there, such as the fact
that we use an archive file even though it almost always has only one
member. I think this was before we had the idea of using the first
letter of an identifier to indicate whether it was exported or not.
Source files of a package would actually import the package itself in
order to see identifiers in other files in the same package, and we
had a gobuild program that would try building the files in various
orders until it found one that worked. You can still see this in the
source code history--gobuild was added in revision 4b37d2fab562.
Anyhow at least for a little while we had the idea that declarations
would be file scoped by default, or package scoped if preceded by the
keyword "package" (yes, we actually used that keyword for something
meaningful once) or exported from the package if preceded by the
keyword "export." Or something like that, I'm probably forgetting
exactly how it worked.

Even today we one kind of file scoped declaration: the local name of
an imported package. And of course imports in general are file-scoped
in a sense, since they aren't visible to other files in the same
package.

The current language is a lot simpler.

Ian

[Dave Cheney]

Wow. Thanks Ian, that is an amazing piece of history.