POLL: Remove usingnamespace

Brainstorming
41

I haven’t ever used usingnamespace myself.

Reading through the github issue, it seems to me that there are a few different usecases for the keyword.

  1. The same as, for example, C++'s using namespace. This really just hurts readability IMO. It’s fine if you have an LSP and can jump to definition, but if you don’t, it’ll take much longer to find the definition of a symbol, as it could be a part of one of possibly hundreds of zig source files.
  2. Mixins. As far as I can tell, the @fieldParentPtr() builtin lets you make mixins just as well and I find @fieldParentPtr() slightly more readable generally.
  3. Switching on one of a few different namespaces. I like the alternative with multiple switches for each function better for a few reasons. I think it removes a layer of indirection which can make it easier to understand. I also believe that having the more explicit error cases makes it easier to figure out on which platforms a function isn’t available when reading through the code.
  4. Merging namespaces. I feel like this isn’t really an issue that needs to be resolved. Either have one big file with all the source code or use multiple namespaces, they’re both fine. If you can’t think of a good way to separate anything out of a 50K LOC file and into another namespaces then you’re probably not thinking hard enough.

To me at least, it seems that all the reasonable usecases are covered and I agree with the sentiment that “namespaces are always good”. While yes, it is probably possible to come up with a usecase in which you’d rather not have a namespace, I believe there are many more false positives which impact readability to a much greater extent.

42

Just pointing out that in C++ you’re right that coding guidelines discourage its use in production code. However, for teaching code, it’s quite common to see using namespace std to decrease the visual clutter of requiring std:: in front of every standard library function call.

I haven’t read the proposal for zig but I am concerned about the usecase:

pub usingnamespace @cImport({
    @cInclude("sqlite3.h");
});

which I use to bring SQLite3’s C API into a single c namespace with an enclosing const c = @import("c.zig");

It would be dramatically inconvenient (as in, find-a-different-language-to-interoperate-with-C-inconvenient) if everything had to be explicitly declared, so I can’t imagine that would be considered.

43

Can you not just do this for your use case?
c.zig

pub const c = @cImport({
    @cInclude("sqlite3.h");
});

Other file

pub const c = @import("c.zig").c;

Maybe change the names :person_shrugging:

2 Likes
44

Beyond what @GigaGrunch notes, @cImport has already been slated to be axed in favor of having C Dependencies be declared in the build.zig. See: cImport going away

2 Likes
45

used to use namespaces as mixins and it is pretty intuitive comparing with method with @fieldParentPtr… proposed method is not elegant and tend to explode with necessity to render more names, that is prone to design issues

1 Like
46

Oh… this works too, today I learned. Easy enough. Thank you!

1 Like
47

hello,

I’m using usingnamespace, and in my example, I can’t figure out how to do without it. Could you please help me? It’s an integral part of my engine. Thank you.

pub usingnamespace struct {
        pub const ZtxtIterator = struct {
            Ztxt: *const Ztxt,
            index: usize,

            pub fn next(it: *ZtxtIterator) ?[]const u8 {
                if (it.Ztxt.buffer) |buffer| {
                    if (it.index == it.Ztxt.size) return null;
                    const i = it.index;
                    it.index += Ztxt.getUTF8Size(buffer[i]);
                    return buffer[i..it.index];
                } else {
                    return null;
                }
            }
        };

        pub fn iterator(self: *const Ztxt) ZtxtIterator {
            return ZtxtIterator{
                .Ztxt = self,
                .index = 0,
            };
        }
    };
48

Just remove the pub usingnamespace struct { and the closing };.

1 Like