I'd like to have unusing

[Bonita Montero]

In a header I'm fixed to write the std::-prefixes since I can't use
"using namespacee std" because this would be against the exepectations
of those including the header.
So I had a simple idea: with every "using namespace xxx" an counter for
the namespace xxx would be incremented and at the end of block where the
prefixes where used implicitly there would be a new "unusing"-directive
that derements the counter and when it becomes zero, the implicit
attachment to symbols is disabled.

[Alf P. Steinbach]

A workaround until you get that feature proposed and adopted, is to use
a clean /exporting namespace/.

For example, you may want the stuff to be available in namespace `bonitas`.

Then do like this, first defining stuff in the /defining/ namespace
`bonitas::_`, or whatever, really, just not same as exporting ns:

// Here a stern admonition to not use namespace bonitas::_.
// Then:
namespace bonitas::_ {
using namespace std; // Oh joy
void stuff() { feclearexcept(FE_ALL_EXCEPT); }
}

namespace bonitas {
using _::stuff;
}

Regarding `_` a main difference from the usual `impl` or `detail`
namespace (e.g. Boost's `detail`) is that `_` here contains stuff meant
to be used directly by client code, not just implementation details.

However, client code is only meant to use the stuff via the exporting
namespace(s), here bonitas, which itself is/are clean.

There are countless variations and extensions of the scheme, and there
is a gotcha about templates that client code is meant to specialize.


- Alf (who's gradually started to adopt this scheme)

[Öö Tiib]

On Thursday, 12 December 2019 14:51:17 UTC+2, Alf P. Steinbach wrote:
> Regarding `_` a main difference from the usual `impl` or `detail`
> namespace (e.g. Boost's `detail`) is that `_` here contains stuff meant
> to be used directly by client code, not just implementation details.

Also name `_` conflicts/hides all the libraries that thought no
one else is so clever to use name `_` in interface (like GNU gettext
and several others).

[bol...@nowhere.co.uk]

On Thu, 12 Dec 2019 13:51:00 +0100
"Alf P. Steinbach" <alf.p.stein...@gmail.com> wrote:
>Regarding `_` a main difference from the usual `impl` or `detail`
>namespace (e.g. Boost's `detail`) is that `_` here contains stuff meant
>to be used directly by client code, not just implementation details.

Or alternatively instead of '_' you could use a proper name which would be
easy to find when grepping through code instead of something that could bring
up 1000s of hits. But that would be sensible programming, not a concept you're
very familiar with.

[Alf P. Steinbach]

If there are such badly designed libraries, it would in my opinion be an
added bonus if the name made it difficult to use them.

However I fail to see how that happy situation could come about.

Note that `_` is not is not used or necessarily seen by client code,
i.e. it's not part of interface.

- Alf

[Alf P. Steinbach]

On 12.12.2019 14:47, Öö Tiib wrote:

[Öö Tiib]

The GNU gettext is relatively popular library for i18n in open source.
It uses `_` everywhere there are texts to localize in code:

printf(_("Report bugs to <%s>.\n"), PACKAGE_BUGREPORT);

So its usages can be found by searching for `_("`.

[Mr Flibble]

Worst. Idea. Ever.

/Flibble

--
"Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin

“You won’t burn in hell. But be nice anyway.” – Ricky Gervais

“I see Atheists are fighting and killing each other again, over who doesn’t believe in any God the most. Oh, no..wait.. that never happens.” – Ricky Gervais

"Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say."

[Mr Flibble]

On 12/12/2019 18:29, Mr Flibble wrote:
> On 12/12/2019 11:49, Bonita Montero wrote:
>> In a header I'm fixed to write the std::-prefixes since I can't use
>> "using namespacee std" because this would be against the exepectations
>> of those including the header.
>> So I had a simple idea: with every "using namespace xxx" an counter for
>> the namespace xxx would be incremented and at the end of block where the
>> prefixes where used implicitly there would be a new "unusing"-directive
>> that derements the counter and when it becomes zero, the implicit
>> attachment to symbols is disabled.
>
> Worst. Idea. Ever.

What would be a good idea tho would be the following feature:

namespace neogfx
{
// foo

namespace ::std
{
// stuff you want to specialize in std
}

// bar
}

so we don't have to write:

namespace neogfx
{
// foo
}

namespace std
{
// stuff you want to specialize in std
}

namespace neogfx
{
// bar

[Bonita Montero]

>> In a header I'm fixed to write the std::-prefixes since I can't use
>> "using namespacee std" because this would be against the exepectations
>> of those including the header.
>> So I had a simple idea: with every "using namespace xxx" an counter for
>> the namespace xxx would be incremented and at the end of block where the
>> prefixes where used implicitly there would be a new "unusing"-directive
>> that derements the counter and when it becomes zero, the implicit
>> attachment to symbols is disabled.

> Worst. Idea. Ever.

No, very good idea.

[Daniel]

On Thursday, December 12, 2019 at 1:34:37 PM UTC-5, Mr Flibble wrote:
>
> What would be a good idea tho would be the following feature:
>
> namespace neogfx
> {
> // foo
>
> namespace ::std
> {
> // stuff you want to specialize in std
> }
>
> // bar
> }
>
> so we don't have to write:
>
> namespace neogfx
> {
> // foo
> }
>
> namespace std
> {
> // stuff you want to specialize in std
> }
>
> namespace neogfx
> {
> // bar
> }
>

Totally agree. Especially for the case where something like the above has to
be wrapped in another namespace.

Daniel

[Mr Flibble]

In your opinion; unfortunately you haven't thought through the implications of what you are suggesting. It is a *really* bad idea.

[Bonita Montero]

>> No, very good idea.

> In your opinion; unfortunately you haven't thought through the
> implications of what you are suggesting.  It is a *really* bad idea.

Then tell me the implications.

[Alf P. Steinbach]

Oh, that's ugly.

But I still don't see the conflict, if that's a macro with params.

Example?


- Alf

[Pavel]

I personally don't see anything wrong in defining few things in details
and using one in the outward-facing namespace (it is not unnatural if
public API is a proper subset of "all details"). But if the namespace
`detail' actively jumps at you as intended for implementation-specific
things exclusively, why not be explicit and use something like using_std
namespace:

namespace mylib {
namespace using_std {
using namespace std;
// define stuff heavily using things from std:: , in particular `stuff'
// that is a part of mylib API
}
using using_std::stuff;
}

Using identifiers beginning with _ in application programs is at least
frown upon by the Standard ("shall not be used otherwise [than by
implementation]"), see 5.10-3.2 in n4830.

[Alf P. Steinbach]

Identifiers starting with `_` are reserved in the global namespace.

Identifiers starting with `_` followed by uppercase letter are reserved
everywhere.

I don't recall any rule like the one you imply, so I think you're
looking at either the C standard or a proposal of some sort.

[Pavel]

I referred to n4830 5.10 (you can call it a proposal but I doubt
anything will change in this particular regard):

3 In addition, some identifiers are reserved for use by C++
implementations and shall not be used otherwise; no
diagnostic is required.
(3.1) — Each identifier that contains a double underscore __ or begins
with an underscore followed by an
uppercase letter is reserved to the implementation for any use.
(3.2) — Each identifier that begins with an underscore is reserved to
the implementation for use as a name in
the global namespace.

Approximately same text was in C++ 11 Standard:

17.6.4.3.2 Global names [global.names]
1 Certain sets of names and function signatures are always reserved to
the implementation:
— Each name that contains a double underscore _ _ or begins with an
underscore followed by an uppercase
letter (2.12) is reserved to the implementation for any use.
— Each name that begins with an underscore is reserved to the
implementation for use as a name in the
global namespace.

So, _ is not just reserved for use as a name in the global namespace but
is reserved *for use by by C++ implementation* (n4830) or *to the
implementation* (2011 Standard).

bonitas::_ is neither used by C++ implementation nor a name in the
global namespace so it seems not compliant to either the 2011 Standard
or n4830 on both fronts.

[Alf P. Steinbach]

That doesn't follow from what you quote.

What you quote now is what I told you.

In addition, what you quote now does not contain the text you quoted out
of context earlier.

> bonitas::_ is neither used by C++ implementation nor a name in the
> global namespace so it seems not compliant to either the 2011 Standard
> or n4830 on both fronts.

And this does not make sense.

[Pavel]

It does.

>
> What you quote now is what I told you.

You have never mentioned that names or identifiers beginning with an
underscore were reserved for use by / to C++ implementation.

>
> In addition, what you quote now does not contain the text you quoted

3 In addition, some identifiers are reserved for use by C++

implementations and *shall not be used otherwise*; no
diagnostic is required.

"shall not be used otherwise" is the only clause I really quoted "earlier".
> out of context
define the context

> earlier.

>
>
>> bonitas::_ is neither used by C++ implementation nor a name in the
>> global namespace so it seems not compliant to either the 2011 Standard
>> or n4830 on both fronts.
>
> And this does not make sense.

How so?

[Öö Tiib]

On Thursday, 26 December 2019 00:06:27 UTC+2, Pavel wrote:
> Alf P. Steinbach wrote:

> > On 25.12.2019 22:37, Pavel wrote:
> >
> >> bonitas::_ is neither used by C++ implementation nor a name in the
> >> global namespace so it seems not compliant to either the 2011 Standard
> >> or n4830 on both fronts.
> >
> > And this does not make sense.
> How so?

I also do not get your logic how it is not compliant.
It is not in global namespace nor contains double underscores
nor starts with underscore followed by capital letter and so
it is compliant. I don't like it ... but it is just matter of taste.

[Pavel]

I see. My logic is this: from the below:

3 In addition, some identifiers are reserved for use by C++
implementations and shall not be used otherwise; no
diagnostic is required.
(3.1) — Each identifier that contains a double underscore __ or begins
with an underscore followed by an
uppercase letter is reserved to the implementation for any use.
(3.2) — Each identifier that begins with an underscore is reserved to

the implementation for use as a name in
the global namespace.

I make 2 conclusions:

A. some identifiers (in particular those starting with _) shall not be
used by otherwise than by C++ implementation
B. If an identifier starting with _ not followed by an uppercase letter
is used by C++ implementation, it should be used as a name in the global
namespace.

From that it follows that:

- bonitas::_ is not allowed because of A.
- if A. did not exist, it would be still not allowed because of the
clause Alf referred to in his recollection of the Standard, namely:

Identifiers starting with `_` are reserved in the global namespace.

What I am missing?

[Alf P. Steinbach]

The parenthetical remark does not follow from anything.

> B. If an identifier starting with _ not followed by an uppercase letter
> is used by C++ implementation, it should be used as a name in the global
> namespace.

... or namespace `std`.

> From that it follows that:
>
> - bonitas::_ is not allowed because of A.
> - if A. did not exist, it would be still not allowed because of the
> clause Alf referred to in his recollection of the Standard, namely:
>
> Identifiers starting with `_` are reserved in the global namespace.
>
> What I am missing?

Rather, the question is where you get these ideas.


- Alf

[Pavel]

except it follows from 3.2 cited right above

>
>
>> B. If an identifier starting with _ not followed by an uppercase letter
>> is used by C++ implementation, it should be used as a name in the global
>> namespace.
>
> ... or namespace `std`.

*that* is what does not seem to follow from anything.

>
>
>>  From that it follows that:
>>
>> - bonitas::_ is not allowed because of A.
>> - if A. did not exist, it would be still not allowed because of the
>> clause Alf referred to in his recollection of the Standard, namely:
>>
>> Identifiers starting with `_` are reserved in the global namespace.
>>
>> What I am  missing?
>
> Rather, the question is where you get these ideas.

Oh, the answer to this one is simple: boolean logic applied to A and B
above.
>
>
> - Alf

[Alf P. Steinbach]

This reminds me strongly of the tortoise's denial arguments in
Hofstadter's "Gödel, Escher, Bach: An Eternal Golden Braid".

I recommend that book.

- Alf

[Pavel]

nice try.
>
> - Alf

[Öö Tiib]

Sometimes I notice hieroglyph fi used instead of fi in normative texts.
Like "identifier". Perhaps there is saboteur among the language lawyers
that wants to make it harder to search the texts.

> >> I make 2 conclusions:
> >>
> >> A. some identifiers (in particular those starting with _) shall not be
> >> used by otherwise than by C++ implementation
> >
> > The parenthetical remark does not follow from anything.
> except it follows from 3.2 cited right above

I understand how the sentence may be interpreted like that out of
context but that interpretation does not make sense in C++.

Names have scope in C++ (or can lack it on case of macros and keywords).
So "as names in the global namespace" means that it is where the
rule applies. Similarly "for any use" means that such names are
reserved for any (scoped or scope-less) usage.

Characters of Alice in Wonderland kept constantly misinterpreting
meanings of sentences like that so perhaps it is just limitation
of human languages. Or can you propose better wording?

> >
> >
> >> B. If an identifier starting with _ not followed by an uppercase letter
> >> is used by C++ implementation, it should be used as a name in the global
> >> namespace.
> >
> > ... or namespace `std`.
> *that* is what does not seem to follow from anything.

There standard has chosen to other way of reserving, the menace
of undefined behavior when user touches namespace std in wrong
way:
"The behavior of a C++ program is undefined if it adds declarations
or definitions to namespace std or to a namespace within namespace
std unless otherwise specified. A program may add a template
specialization for any standard library template to namespace std
only if the declaration depends on a user-defined type and the
specialization meets the standard library requirements for the original
template and is not explicitly prohibited."

> >
> >
> >>  From that it follows that:
> >>
> >> - bonitas::_ is not allowed because of A.
> >> - if A. did not exist, it would be still not allowed because of the
> >> clause Alf referred to in his recollection of the Standard, namely:
> >>
> >> Identifiers starting with `_` are reserved in the global namespace.
> >>
> >> What I am  missing?
> >
> > Rather, the question is where you get these ideas.
> Oh, the answer to this one is simple: boolean logic applied to A and B
> above.

English does not unfortunately translate into boolean logic.
No human language does.

> >
> >
> > - Alf

[Öö Tiib]

On Thursday, 26 December 2019 13:01:25 UTC+2, Öö Tiib wrote:
> On Thursday, 26 December 2019 02:55:04 UTC+2, Pavel wrote:
> > Alf P. Steinbach wrote:
> > > On 25.12.2019 23:28, Pavel wrote:
> > >
> > >> B. If an identifier starting with _ not followed by an uppercase letter
> > >> is used by C++ implementation, it should be used as a name in the global
> > >> namespace.
> > >
> > > ... or namespace `std`.
> > *that* is what does not seem to follow from anything.
>
> There standard has chosen to other way of reserving, the menace
> of undefined behavior when user touches namespace std in wrong
> way:
> "The behavior of a C++ program is undefined if it adds declarations
> or definitions to namespace std or to a namespace within namespace
> std unless otherwise specified. A program may add a template
> specialization for any standard library template to namespace std
> only if the declaration depends on a user-defined type and the
> specialization meets the standard library requirements for the original
> template and is not explicitly prohibited."

Note that by your interpretation, Pavel, standard is violating itself:
<https://en.cppreference.com/w/cpp/utility/functional/placeholders>

[Richard Damon]

Those names are reserved for the Standard to use. There is absolutely
nothing in the Standard that prohibit it from taking a particular name
in that set and defining it for use by the user. In fact, that is one of
the reason that in C, the 'true name' for the boolean type is _Bool, as
that was a name that was reserved for the implementation, and thus
should not legally have previously appeared in any user code, so no
backwards breakage introducing it (many user applications had a type
called bool defined in many different ways). It was only by including a
specific header that the symbol bool got its now standard definition, so
old programs could stay valid as they didn't include that header and new
programs could include the header and get the nice name.

Note the words, "unless otherwised specified", That section you
reference specifies a particular set of symbols and how they can be used.

[Öö Tiib]

On Friday, 27 December 2019 18:24:12 UTC+2, Richard Damon wrote:
> On 12/26/19 6:20 AM, Öö Tiib wrote:
> > On Thursday, 26 December 2019 13:01:25 UTC+2, Öö Tiib wrote:
> >> On Thursday, 26 December 2019 02:55:04 UTC+2, Pavel wrote:
> >>> Alf P. Steinbach wrote:
> >>>> On 25.12.2019 23:28, Pavel wrote:
> >>>>
> >>>>> B. If an identifier starting with _ not followed by an uppercase letter
> >>>>> is used by C++ implementation, it should be used as a name in the global
> >>>>> namespace.
> >>>>
> >>>> ... or namespace `std`.
> >>> *that* is what does not seem to follow from anything.
> >>
> >> There standard has chosen to other way of reserving, the menace
> >> of undefined behavior when user touches namespace std in wrong
> >> way:
> >> "The behavior of a C++ program is undefined if it adds declarations
> >> or definitions to namespace std or to a namespace within namespace
> >> std unless otherwise specified. A program may add a template
> >> specialization for any standard library template to namespace std
> >> only if the declaration depends on a user-defined type and the
> >> specialization meets the standard library requirements for the original
> >> template and is not explicitly prohibited."
> >
> > Note that by your interpretation, Pavel, standard is violating itself:
> > <https://en.cppreference.com/w/cpp/utility/functional/placeholders>
> >
>
> Those names are reserved for the Standard to use.

Nope. *All* *and* *every* name, including but not limited to plain and
pure profanities with and without underlines anywhere, in namespace std
or in namespaces within namespace std are reserved for the Implementation
to define or to declare by quoted above Word Of Standard. ;)

> There is absolutely
> nothing in the Standard that prohibit it from taking a particular name
> in that set and defining it for use by the user.

Sure, I totally disagree with interpretation of Paul. In fact the
placeholders I cited were as example of contradiction of his
claim B that those names may be only used by Implementation and
only in global namespace.

> In fact, that is one of
> the reason that in C, the 'true name' for the boolean type is _Bool, as
> that was a name that was reserved for the implementation, and thus
> should not legally have previously appeared in any user code, so no
> backwards breakage introducing it (many user applications had a type
> called bool defined in many different ways). It was only by including a
> specific header that the symbol bool got its now standard definition, so
> old programs could stay valid as they didn't include that header and new
> programs could include the header and get the nice name.

Yes but do not talk about what C does to those smug language lawyers of
C++ committee. Significant part of those would make the two languages
totally incompatible if only to give chance.

> Note the words, "unless otherwised specified", That section you
> reference specifies a particular set of symbols and how they can be used.

What section? I quoted first paragraph of [namespace.std] from C++17.

[Pavel]

Sorry, I did not mean to be impolite, just bailed out earlier than saw your
follow-ups. Happy New Year, BTW.

Placeholders in std:: like _1 etc do seem to break (3.2) I cited. Should be a
defect in the Standard (surely not first and probably not last).

As for my opinion that "those names may be only used by Implementation and
only in global namespace" I deduce it from "and shall not be used otherwise".
Said strongly enough for me to refrain from using these ever (but I did not
anyway since the late 80s because compatibility with C mattered for my purposes
back then).

[Öö Tiib]

Happy new year to you too. And happy name change from Paul to Pavel.
I had odd dream today that someone had changed my name. So I woke up
and looked into group and noticed that my name was same but yours had
changed.

> Placeholders in std:: like _1 etc do seem to break (3.2) I cited. Should be a
> defect in the Standard (surely not first and probably not last).

If you think it is defect then post defect report to isocpp groups.
Language lawyers there will attempt to shred you into threads or
deal with that ambiguity in some other manner but on any case it
will be interesting experience.
<https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion>

> As for my opinion that "those names may be only used by Implementation and
> only in global namespace" I deduce it from "and shall not be used otherwise".
> Said strongly enough for me to refrain from using these ever (but I did not
> anyway since the late 80s because compatibility with C mattered for my
> purposes back then).

What I posted was interpretation how most people had interpreted it.
I myself simply dislike somewhat names with underscores and so I
do not use these anyway. Only place where I use underscore is
that I tend to mark private data members with trailing underscore
to make access of those to stand out.

[Richard Damon]

On 1/2/20 11:47 PM, Pavel wrote:
> As for my opinion that "those names may be only used by Implementation and
> only in global namespace" I deduce it from "and shall not be used otherwise".
> Said strongly enough for me to refrain from using these ever (but I did not
> anyway since the late 80s because compatibility with C mattered for my purposes
> back then).

That phrase means that those names are reserved for the implementation
or the standard to give a meaning to. Where one of these provides a
documented usage, the program is allowed to use that usage.

[Pavel]

My name has always been Pavel. I can see you answered to me (at least my
news reader shows "Pavel") but called me Paul (I have no problem going
for Paul though because it is the proper translation of Pavel to English
so no worry).

>
>> Placeholders in std:: like _1 etc do seem to break (3.2) I cited. Should be a
>> defect in the Standard (surely not first and probably not last).
>
> If you think it is defect then post defect report to isocpp groups.
> Language lawyers there will attempt to shred you into threads or
> deal with that ambiguity in some other manner but on any case it
> will be interesting experience.
> <https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion>
>

Maybe later. This does not seem of practical importance. I might ask my
colleague who is active on the committee but he probably won't be
interested either (but we will see).

>> As for my opinion that "those names may be only used by Implementation and
>> only in global namespace" I deduce it from "and shall not be used otherwise".
>> Said strongly enough for me to refrain from using these ever (but I did not
>> anyway since the late 80s because compatibility with C mattered for my
>> purposes back then).
>
> What I posted was interpretation how most people had interpreted it.
> I myself simply dislike somewhat names with underscores and so I
> do not use these anyway. Only place where I use underscore is
> that I tend to mark private data members with trailing underscore
> to make access of those to stand out.

Same here.
>
>

[Pavel]

Sorry, I should have said "enough for me to refrain from
declaring/defining these ever" as per the original controversy. Of
course I used those that were provided by the implementation (attribute
names and gcc built-ins come to mind).