C++ Logo


Advanced search

Re: [std-proposals] Grouped-namespace "using" statements (floating the idea)

From: Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
Date: Wed, 26 Apr 2023 09:20:58 -0400
FWIW, I'm strongly opposed to this. (And I did a double-take at Barry's
post: is it April Fool's Day already?) C++ isn't Perl; we don't use Unix
shell globs like that. In C++, curly braces have a couple of different
meanings (code block, initializer-sequence), but not "shell glob."

(1) Ville has shown C++'s existing syntax for this:
    namespace LVT = longish::verbosish::tedious;
    using LVT::X;
    using LVT::Y;
    using LVT::Z;

(2) It is a long-standing guideline that you shouldn't introduce multiple
declarations on the same line of code.
    int x, y, z; // worse

    int x;
    int y;
    int z; // better

(3) The "zero, one, infinity" rule. In practice, `using`-declarations
rarely come in twos and threes. There's either one using-declaration (e.g.
to enable ADL
<https://quuxplusone.github.io/blog/2022/04/30/poison-pill-redux/>), or
hundreds (e.g. in the implementation of the <cmath> header
Neither scenario is a good one for this proposed (mis)feature. Anytime
this feature saves a significant amount of typing, the result will be
unfriendly to the human reader — and the code isn't likely to have been
generated by a human typist in the first place.

(4) Another meaning of "C++ isn't Perl": We don't *need* to assign a
meaning to every single sequence of ASCII characters. It's okay for some
sequences of characters to be syntax errors; or to be reserved for future
standardization, until we come up with a feature that is so useful that it
deserves a dedicated syntax. The mere fact that "::{" is currently
unassigned, is not an argument in favor of giving it *this* meaning.

John: Did you know about
    namespace XYZ = longish::verbosish::tedious;
before this week? Now that you know about it, does it adequately solve
your problem?


On Wed, Apr 26, 2023 at 12:29 AM Andrew Tomazos via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> I think I'm cool with this too. John: Can you write a proposal addressed
> to EWGI? Do you know how? Have you done it before? Let us know if you
> need help. -Andrew
> On Wed, Apr 26, 2023 at 12:34 PM Barry Revzin via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>> On Mon, Apr 24, 2023, 9:52 AM John Filleau via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>>> Floating the idea for Grouped-namespace "using" statements.
>>> A grouped-namespace using statement is a shorter way to write multiple
>>> using statements that share a parent namespace.
>>> using a::b::c::X, a::b::c::Y, a::b::c::Z;
>>> can be replaced with
>>> using a::b::c::{X, Y, Z};
>>> Sometimes I have long namespace names, and I want to alias things from
>>> that namespace. The current way to do that requires me to retype the
>>> namespace a lot. See above.
>>> This is annoying at time-of-writing because of the repetition and
>>> opportunity for typos. This is annoying at time-of-maintenance when
>>> namespace names change.
>>> Allow grouped-namespace using statements as seen above.
>>> 100% ergonomics.
>>> This solves no interesting computer science problems, nor does it
>>> introduce world peace.
>>> I have 0 understanding of the edge cases around this. I just know I want
>>> it. If other people want it, we should make it part of the standard.
>>> COST
>>> One more thing that implementations have to handle.
>> I like this idea. Saves on repeating the namespace, which has very little
>> benefit at that point. Plus it's common for people to just avoid using
>> namespace in preference to using declarations, which are quite verbose
>> today due to the namespace repetition.
>> Even if the namespace is short, like:
>> using std::cout, std::endl;
>> This kind of stuff adds up fast, and
>> using std::{cout, endl};
>> is just clearer.
>> You can't have a { after :: today, so there's no ambiguity. This does
>> make parsing a using declaration more complicated, since it's no longer
>> just a sequence of qualiifed-ids, but it's probably not exceedingly
>> difficult.
>> Barry
>>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

Received on 2023-04-26 13:21:12