C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Export namespaces without namespace block, only keyword (modules)

From: Zopolis0 <creatorsmithmdt_at_[hidden]>
Date: Fri, 2 Sep 2022 22:36:35 +1000
Would allowing namespaces to be set in this way increase the use of the
preprocessor over wrapping files in a namespace block?

On Tue, 16 Aug 2022 at 04:54, Julien Villemure-Fr├ęchette via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> > When using headers, it is quite easy to make the functions accessible
> through namespaces > without wrapping the entire file in a namespace block.
> Simply wrap the list of functions in the header in a namespace block and
> prepend the namespace onto the functions in the file.
>
> Such use of the preprocessor is against good style: in particular, header
> file should not be design to 'capture' context surrounding include
> directives and should only be included from the outermost scope (global)
> and usually before all declarations in the file. (even gcc's own header
> files stick to this rule).
> see:
>
> http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#sf4-include-h-files-before-other-declarations-in-a-file
>
> http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#sf11-header-files-should-be-self-contained
>
> Btw, the hole point of modules is to make it possible to minimize most use
> of the preprocessor.
>
> If this is only a matter of minimizing nesting levels and indentation,
> then you should note that there is a formatting option for this
> (clang-format):
> NamespaceIndentation: Inner, All
>
> Julien V.
>
>
>
> -------- Original Message --------
> From: Jason McKesson via Std-Proposals <std-proposals_at_[hidden]>
> Sent: August 15, 2022 10:01:16 a.m. EDT
> To: std-proposals_at_[hidden]
> Cc: Jason McKesson <jmckesson_at_[hidden]>
> Subject: Re: [std-proposals] Export namespaces without namespace block,
> only keyword (modules)
>
> On Mon, Aug 15, 2022 at 3:46 AM Zopolis0 via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > In short-- I propose that there should be a way (if not multiple) to
> export functions within a namespace from a module without having to wrap
> the functions in a namespace block.
> > A few possibilities for the syntax of doing so are presented below,
> along with the rationale.
> > Suggestions for alternative/additional syntaxes or improvements on the
> ones proposed would be welcome.
> > Briefly:
> > Instead of
> > export module foo;
> >
> > export namespace foo
> > {
> > void bar();
> > }
> > Allow the usage of
> > export module foo;
> > export namespace foo void bar();
> >
> > Haven't really decided on the breadth of the syntax and how many ways
> there would be to declare the namespace, was thinking about a file-wide
> namespace declaration along the lines of:
> > export module foo:
> > export namespace foo;
> > This would set everything exported from module foo to be in namespace
> foo.
>
> Why do you need a shorter way to say that? Namespace names and module
> names probably *shouldn't* always be the same. It would make it
> difficult to use sub-modules, where multiple modules contribute to one
> larger module.
>
> > This of course would not work for multiple namespaces in a file, for
> which the original keyword proposition could be used as a fallback.
> >
> > Rationale:
> > Namespaces are cool. (I see no reason to provide a rationale for the
> usage of namespaces in this proposal.)
> > When using headers, it is quite easy to make the functions accessible
> through namespaces without wrapping the entire file in a namespace block.
> Simply wrap the list of functions in the header in a namespace block and
> prepend the namespace onto the functions in the file.
> >
> >
> > With modules, one has to wrap the entire file in a namespace block, or
> at least the functions they want to export, which is sub-par.
>
> Why is that "sub-par"?
>
> -- Julien Villemure
> Sent from my Android device with K-9 Mail.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>

Received on 2022-09-02 12:36:48