220 35577 <2653ed1f-714b-47e9-94a2-e5aa0d6ca713@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: jake.arkinstall@cambridgequantum.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Templated namespaces Date: Mon, 27 Nov 2017 17:55:59 -0800 (PST) Lines: 260 Approved: news@gmane.org Message-ID: <2653ed1f-714b-47e9-94a2-e5aa0d6ca713@isocpp.org> References: <20171127194050.GA10682@fukushima.lysator.liu.se> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_26412_1241295932.1511834159609" X-Trace: blaine.gmane.org 1511834171 665 195.159.176.226 (28 Nov 2017 01:56:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 28 Nov 2017 01:56:11 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBD47HBX4YECBBMEE6PIAKGQEP5F62EY@isocpp.org Tue Nov 28 02:56:06 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f70.google.com ([209.85.213.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eJV7q-0007aT-L7 for gclcip-std-proposals@m.gmane.org; Tue, 28 Nov 2017 02:55:54 +0100 Original-Received: by mail-vk0-f70.google.com with SMTP id o70sf17365580vkc.17 for ; Mon, 27 Nov 2017 17:56:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=fLwsy/qbs0Am6/XQ4UBYlqlC5mq1uM2wS9G8BVVLlqM=; b=CzOR+XTMwWXjZvnjv4baLOYI2FI5twNH95ejnvC4qbvilDw91U4z5ALMWZgairQr19 LoDZf81VqZCp9Z+mUnQe1/x7peaWoWqM6YpPlxRH6gcMA08bDsEsvmLCOQhPSmxcoNNP 0MmSw3r4Qs0QfRDWfwR9fPAlx071QLWoc/jBdsUjXvPnE/EP4zxIj9DaXkxBcaXTVPYZ FtCwy2V704kYp04jwHW00JkkaoAQiaaQUfNcsM8l01IF1ESZ9evBfXKuopIerkdqhXb5 DcQS2VtIrgejxsjFa/YluNnEucGn9aJAOsK7QeRwchyyylUFnZg/LYZtBsLYXQUEu/mj AWKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=fLwsy/qbs0Am6/XQ4UBYlqlC5mq1uM2wS9G8BVVLlqM=; b=kD6dYS17Py3GIQWkuC/HQccekEofoc+sXy6/J8PQkekjCa5htwtRv+I5nPyo36VAo8 xNZ8O1USZtG2ZpqxeM73yEmZxqebCmGCv26aZtmc5w5iCjes+hHd5HGUVwgHmFC3HwJQ Gl00yL7G1KiS1I4HjtYh6LHGoBpBKWLRP0GlqS+WsvDsAapZ37w5ayqzfogdqI0sE0jN O3R1ZRyr+mhR8k/A3z/uc//4tuZ1jkFb4z7DNmA30UxPip3oWcx3XDihlbYt4yCuQfAa Ym2L6QJWzw3Ofo8vxlOupypJwxtE2UhIqLBNeDOYPYfi7ulwHO5QKTe9c4l6Id0bCvZF Dxqw== X-Gm-Message-State: AJaThX6Q8XlAzjvKYAYgxLW5nVy39n7btAczeZrSz+f0jg2F+jF4lOsO i1VhE9Lf1sOCAY/enNS6BmBqng== X-Google-Smtp-Source: AGs4zMaiI4TIt0HoIf14c23/UB9eqlyUfKNsVrLZBoZJv7sa/tbReWRzkcy84JcN7e+lFyKyGXtPow== X-Received: by 10.31.235.1 with SMTP id j1mr17665029vkh.16.1511834161814; Mon, 27 Nov 2017 17:56:01 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.151.69 with SMTP id z66ls3988816vkd.16.gmail; Mon, 27 Nov 2017 17:56:00 -0800 (PST) X-Received: by 10.31.61.142 with SMTP id k136mr3689449vka.5.1511834160097; Mon, 27 Nov 2017 17:56:00 -0800 (PST) In-Reply-To: X-Original-Sender: jake.arkinstall@cambridgequantum.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:35577 Archived-At: ------=_Part_26412_1241295932.1511834159609 Content-Type: multipart/alternative; boundary="----=_Part_26413_1433417922.1511834159610" ------=_Part_26413_1433417922.1511834159610 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > I have now looked over the discussion, though I actually have some major= =20 > disagreements with the conclusion. I will address them in full in a later= =20 > reply. > And now I shall do just that. In fact, after reading through again, I can see that there wasn't really a= =20 conclusion, per se. It went out not with a bang, but with a whimper - which= =20 gives me hope. - *"Namespaces don't have a unique definition and are only affecting=20 naming."* That is not a necessary property of namespaces - just the unfortunate=20 situation that we are currently in. Namespaces could be used with more= =20 power if we allow them to be used to describe classes united with the sa= me=20 template structures. - *"Namespaces differ from classes in that they can be split within and= =20 amongst translation units"* I don't quite see this as a problem, but as a consideration. If=20 namespaces are to be templated, they should only be considered the "same= "=20 namespace if those template parameters match. If the set of parameters i= s=20 different, they aren't considered equivalent (but I see no reason for it= to=20 be an error). Current approach: =20 namespace A { template class B {};}namespace A { template class C : B {};}namespace A { template class D : B{}; // Uh-oh - too many template arguments =20 } New approach, using templates: =20 templatenamespace A { class B {};} templatenamespace A { class C : B {};} templatenamespace A { class D : B{}; // A::B undeclared} =20 =20 -=20 *"Namespaces can contain the following declarations, whereas classes=20 cannot" * explicit-instantiation explicit-specialization linkage-speci=EF=AC=81cation namespace-de=EF=AC=81nition attribute-declaration asm-de=EF=AC=81nition namespace-alias-de=EF=AC=81nition using-directive opaque-enum-declaration =20 This is something I'm going to need to go through with a fine-tooth=20 comb. I may need assistance with this. *However, *should any such=20 declaration seem incompatible with the idea of templated namespaces, it= =20 could be disabled for templated namespaces without disrupting the=20 functionality of non-templated namespaces. This may be the case with *as= m-definition=20 - *not something I have used, I must admit, but I can see how having=20 many copies of an asm-definition might be unfortunate. On the other hand= ,=20 if only functions, objects, and sub-namespaces inside a templated namesp= ace=20 are provided with templating, whilst other declarations are only declare= d=20 *once.* =20 =20 --=20 You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/2653ed1f-714b-47e9-94a2-e5aa0d6ca713%40isocpp.or= g. ------=_Part_26413_1433417922.1511834159610 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I have= now looked over the discussion, though I actually have some major disagree= ments with the conclusion. I will address them in full in a later reply.


And now I shall do just that.

In fact, after = reading through again, I can see that there wasn't really a conclusion,= per se. It went out not with a bang, but with a whimper - which gives me h= ope.

  • "Namespaces don't have a unique = definition and are only affecting naming."
    That is not a necess= ary property of namespaces - just the unfortunate situation that we are cur= rently in. Namespaces could be used with more power if we allow them to be = used to describe classes united with the same template structures.
  • = "Namespaces differ from classes in that they can be split within an= d amongst translation units"
    I don't quite see this as a pr= oblem, but as a consideration. If namespaces are to be templated, they shou= ld only be considered the "same" namespace if those template para= meters match. If the set of parameters is different, they aren't consid= ered equivalent (but I see no reason for it to be an error). Current approa= ch:
    na=
mespace A {
	template<=
span style=3D"color: rgb(128, 0, 128);"><typename T>
	class B <=
span style=3D"color: rgb(128, 0, 128);">{};
}
namespace =
A {
	template<=
span style=3D"color: rgb(128, 0, 128);"><typename S>
	class C <=
span style=3D"color: rgb(128, 0, 128);">: B<S> {};
}
namespace =
A {
	template<=
span style=3D"color: rgb(128, 0, 128);"><typename T, size_t X>
	class D <=
span style=3D"color: rgb(128, 0, 128);">: B<T,X>{}; // Uh-oh - too many template arguments

    }

New approach, using templates:
    

    template<typename T>
namespace =
A {
	class B <=
span style=3D"color: rgb(128, 0, 128);">{};
}

template<typename T>
namespace =
A {
	class C <=
span style=3D"color: rgb(128, 0, 128);">: B {}<=
span style=3D"color: rgb(128, 0, 128);">;
}

template<typename T, size_t X>
namespace =
A {
	class D <=
span style=3D"color: rgb(128, 0, 128);">: B{}; // A<T,X>::B undeclared
}
  • "Namespaces can contain the following declara= tions, whereas classes cannot"
    explicit-instantiation
    explicit-specialization
    linkage-speci=EF=AC=81cation
    namespace-de=EF=AC=81nition
    attribute-declaration
    asm-de=EF=AC=81nition
    using-directive
    = opaque-enum-declaration

    This is something I'm going to need to= go through with a fine-tooth comb. I may need assistance with this. How= ever, should any such declaration seem incompatible with the idea of te= mplated namespaces, it could be disabled for templated namespaces without d= isrupting the functionality of non-templated namespaces. This may be the ca= se with asm-definition - not something I have used, I must admit, bu= t I can see how having many copies of an asm-definition might be unfortunat= e. On the other hand, if only functions, objects, and sub-namespaces inside= a templated namespace are provided with templating, whilst other declarati= ons are only declared once.

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/2653ed1f-714b-47e9-94a2-e5aa0d6ca713= %40isocpp.org.
------=_Part_26413_1433417922.1511834159610-- ------=_Part_26412_1241295932.1511834159609-- .