I've had another look at your suggestion, Matthew. I've now bought into
your explanation of why it's not really more complicated than what I
suggested. So - I like it.

But there's a bit of a conundrum here. Your proposal makes sense. I also
think my proposal makes sense, and the justification is at least
partially similar, i.e. "Why should a template specification apply to
just a single definition/declaration?" as an example of DRY. Both
proposals are not complicated to implement, it seems.

Now, your suggestion has the advantage of doing more in its use case.
That is, with my suggestion you would write

template <typename T> {
  List<T>::List(...) { ... }
  List<T>& List<T>::operator=3D(List const& other) { ... }
  List<T>::iterator List<T>::find(...) { ... }
}

and with yours it would just be

template <typename T>
namespace class List {
  List(...) { ... }
  List& operator=3D(List const& other) { ... }
  iterator find(...) { ... }
}

on the other hand, your suggestion would not allow for

template<class InputIterator, class Predicate> {
  bool all_of(InputIterator First, InputIterator Last, Predicate Comp);
  bool any_of(InputIterator First, InputIterator Last, Predicate Comp);
}

which my suggestion does allow, and I hope you would agree is useful to
have.

Also, if only one suggestion were accepted, it's not clear there would
be sufficient motivation to accept the other.

I would like to say the solution is a combination of both proposals into
one. In the combination, there are template specification scopes, and
class-namespace scopes. Thus:


template <typename T> {
  namespace class List {
    List(...) { ... }
    List& operator=3D(List const& other) { ... }
    iterator find(...) { ... }
  }
  T foo_which_may_or_may_not_be_related(T x);
}

But then, this is (a bit) more complicated than either of the individual
suggestions.

What do you think? (You =3D Matthew and everybody else)

Eyal




On 04/25/2017 04:57 PM, Matthew Woehlke wrote:
> On 2017-04-24 11:18, eyalroz@technion.ac.il wrote:
>> On Monday, April 24, 2017 at 10:14:12 AM UTC+2, P=C3=A9ter Radics wrote:
>>> There was a proposal a while back about "Class Namespace" (a quick sear=
ch=20
>>> brings up this link, but I'm not sure this is the latest draft:=20
>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0223r0.html).=
=20
>=20
> It is. I didn't get a chance to present it at Jacksonville, but the
> informal feedback I received was that it needed more work. (Alas, now I
> can't recall what folks were wanting...)
>=20
>>> This proposal is smaller in scope then the OPs idea, but would solve th=
e=20
>>> issue for class templates.
>>
>> I actually think that's a more complicated suggestion, since it requires=
=20
>> some resolution work to find the right class.
>=20
> How so? It's a fairly straight-forward transformation. This:
>=20
>   [TEMPLATE] // template <...>
>   namespace CLASS_SPEC {
>     TYPE DECL // e.g. int foo(...)
>   }
>=20
> ...is equivalent to:
>=20
>   [TEMPLATE] TYPE CLASS_SPEC::DECL
>=20
> ...and very nearly equivalent to:
>=20
>   [TEMPLATE] CLASS_SPEC {
>     TYPE DECL
>   };
>=20
> I don't see why the compiler would have to work any harder under the
> proposal than it already needs to today. A simple implementation can
> just memoize the namespace tokens and then transform every declaration
> within the scope using said tokens to match its C++current equivalent.
>=20
>> But be that as it may - what's the status of that proposal? I see that i=
t's=20
>> been 'assigned' to the Evolution subgroup; should I post to that mailing=
=20
>> lists about this whole business?
>=20
> See above. Needs to be presented. Feedback is always appreciated!
>=20
>> Also, do you think it's reasonable/advisable to draft a proposal in a=20
>> similar format and submit it more officially?
>=20
> Please talk to me before submitting a similar proposal; it is probably
> better to update the existing proposal instead, unless you are proposing
> something significantly different. (Even if you want to propose an
> alternative, maybe I would like to help :-).)
>=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/d32aae5b-0098-e356-4629-0a5eab29f746%40technion.=
ac.il.

.

I don't really like "=E2=80=8Etemplate specification scopes", but I'm OK wi=
th "class-namespace scopes"=E2=80=8E.=C2=A0

Not sure why, just my gut instincts.=C2=A0

Class-namespace encloses related items.=C2=A0
Template specs could enclose anything. Sure, a good programmer will only us=
e it wisely, but it is fundamentally just syntactic relationships, not sema=
ntic relationships.=C2=A0
I prefer language constructs that represent semantic properties.


Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A0portable=C2=A0Babbage=C2=A0Devi=
ce
=C2=A0 Original Message =C2=A0
From: Eyal Rozenberg
Sent: Saturday, April 29, 2017 12:49 PM
To: std-proposals@isocpp.org
Reply To: std-proposals@isocpp.org
Cc: d25fe0be@outlook.com
Subject: Re: [std-proposals] Re: Has it been proposed to allow "template <.=
...>" to apply to multiple declarations/definitions?

I've had another look at your suggestion, Matthew. I've now bought into
your explanation of why it's not really more complicated than what I
suggested. So - I like it.

But there's a bit of a conundrum here. Your proposal makes sense. I also
think my proposal makes sense, and the justification is at least
partially similar, i.e. "Why should a template specification apply to
just a single definition/declaration?" as an example of DRY. Both
proposals are not complicated to implement, it seems.

Now, your suggestion has the advantage of doing more in its use case.
That is, with my suggestion you would write

template <typename T> {
List<T>::List(...) { ... }
List<T>& List<T>::operator=3D(List const& other) { ... }
List<T>::iterator List<T>::find(...) { ... }
}

and with yours it would just be

template <typename T>
namespace class List {
List(...) { ... }
List& operator=3D(List const& other) { ... }
iterator find(...) { ... }
}

on the other hand, your suggestion would not allow for

template<class InputIterator, class Predicate> {
bool all_of(InputIterator First, InputIterator Last, Predicate Comp);
bool any_of(InputIterator First, InputIterator Last, Predicate Comp);
}

which my suggestion does allow, and I hope you would agree is useful to
have.

Also, if only one suggestion were accepted, it's not clear there would
be sufficient motivation to accept the other.

I would like to say the solution is a combination of both proposals into
one. In the combination, there are template specification scopes, and
class-namespace scopes. Thus:


template <typename T> {
namespace class List {
List(...) { ... }
List& operator=3D(List const& other) { ... }
iterator find(...) { ... }
}
T foo_which_may_or_may_not_be_related(T x);
}

But then, this is (a bit) more complicated than either of the individual
suggestions.

What do you think? (You =3D Matthew and everybody else)

Eyal




On 04/25/2017 04:57 PM, Matthew Woehlke wrote:
> On 2017-04-24 11:18, eyalroz@technion.ac.il wrote:
>> On Monday, April 24, 2017 at 10:14:12 AM UTC+2, P=C3=A9ter Radics wrote:
>>> There was a proposal a while back about "Class Namespace" (a quick sear=
ch=20
>>> brings up this link, but I'm not sure this is the latest draft:=20
>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0223r0.html).
>=20
> It is. I didn't get a chance to present it at Jacksonville, but the
> informal feedback I received was that it needed more work. (Alas, now I
> can't recall what folks were wanting...)
>=20
>>> This proposal is smaller in scope then the OPs idea, but would solve th=
e=20
>>> issue for class templates.
>>
>> I actually think that's a more complicated suggestion, since it requires=
=20
>> some resolution work to find the right class.
>=20
> How so? It's a fairly straight-forward transformation. This:
>=20
> [TEMPLATE] // template <...>
> namespace CLASS_SPEC {
> TYPE DECL // e.g. int foo(...)
> }
>=20
> ...is equivalent to:
>=20
> [TEMPLATE] TYPE CLASS_SPEC::DECL
>=20
> ...and very nearly equivalent to:
>=20
> [TEMPLATE] CLASS_SPEC {
> TYPE DECL
> };
>=20
> I don't see why the compiler would have to work any harder under the
> proposal than it already needs to today. A simple implementation can
> just memoize the namespace tokens and then transform every declaration
> within the scope using said tokens to match its C++current equivalent.
>=20
>> But be that as it may - what's the status of that proposal? I see that i=
t's=20
>> been 'assigned' to the Evolution subgroup; should I post to that mailing=
=20
>> lists about this whole business?
>=20
> See above. Needs to be presented. Feedback is always appreciated!
>=20
>> Also, do you think it's reasonable/advisable to draft a proposal in a=20
>> similar format and submit it more officially?
>=20
> Please talk to me before submitting a similar proposal; it is probably
> better to update the existing proposal instead, unless you are proposing
> something significantly different. (Even if you want to propose an
> alternative, maybe I would like to help :-).)
>=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/d32aae5b-0098-e356-4629-0a5eab29f746%40technion.=
ac.il.

--=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/20170429171449.5124179.6280.29268%40gmail.com.

.

Well, two declarations/definitions, in the same namespace, in the same
file, appears consecutively, and with the same template parameters are
implicitly related already, I'd say. It's true that your proposal does
not imply stronger relation and mine can be construed that way; but,
well - so what? I mean, if someone wants to emphasize his consecutive
pieces of code are unrelated, then s/he just won't put them in the same
scope.

As for your macro suggestion - come on... even ignoring the general
aversion to macros, that's baroque-looking and confusing, declaring the
template parameters far away from their use (both for your example and
for mine).

Having said that, though, I'll also say I don't think I want to try and
forcefully "push" a suggestion which is met with resistance to the basic
concept. I mean, maybe that's a worthwhile thing to do, but I don't have
the 'psychological resources' to run a sort of a campaign of arguing
with people.

So, if you feel like combining suggestions - I think that would be
great; if not that's also ok and I still support your proposal  (for all
the good that does you...)

Eyal


On 05/02/2017 04:21 PM, Matthew Woehlke wrote:
> On 2017-04-29 12:49, Eyal Rozenberg wrote:
>> Your proposal makes sense. I also think my proposal makes sense, and
>> the justification is at least partially similar, i.e. "Why should a
>> template specification apply to just a single
>> definition/declaration?" as an example of DRY.
>> [...]
>> What do you think? (You = Matthew and everybody else)
>
> The concern I have with your proposal, that I think is shared by others,
> is that your scope is a *pure* token repetition; that is, the template
> parameters of the scope are each *independently* applied to the items
> inside the scope. Compare with P0223 where - yes, even if the
> *implementation* may work similarly - the entities in the scope are
> logically related.
>
> Also, it just occurs to me, I think I can also solve your problem with
> macros:
>
>   #define MY_TEMPLATE \
>     template <typename InputIterator, typename Predicate>
>
>   MY_TEMPLATE bool all_of(InputIterator first, Predicate comp);
>   MY_TEMPLATE bool any_of(InputIterator first, Predicate comp);
>
> ...which lessens the motivation. While I *can* do the same thing for
> classes, it's more awkward:
>
>   #define MY_CLASS_TEMPLATE template <typename T>
>   #define MY_CLASS_CLASS List<T>::
>
>   MY_CLASS_TEMPLATE MY_CLASS_CLASS List(...) { ... }
>   MY_CLASS_TEMPLATE List<T>& MY_CLASS_CLASS operator=(...) { ... }
>   MY_CLASS_TEMPLATE List<T>::iterator MY_CLASS_CLASS find(...) { ... }
>
> Unlike the previous example, this is hardly an improvement over writing
> out everything the long way. Also, P0223 offers an additional benefit
> that doesn't apply to your case; namely, ability to use the class name
> or types that are members of the class without extra qualifiers.
>

--
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 email 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/1b4adafd-e4b8-e5a8-4d58-035fc7cdaff0%40technion.ac.il.

.

--94eb2c054954905bb6054eb51f59
Content-Type: text/plain; charset=UTF-8

I like the class namespace proposal. I've often wished for such a thing as
a clean way of separating interface from implementation in template code.

I'm a little less keen on this proposal because I share the concern that
when I see:
template<typename T> {
  void foo(T param);
  void bar(T param);
}

My brain wants to assume that those Ts are the same.

Whether that matters is open to question, and depends substantially on
whether such a fact would ever be expected to be visible. It may matter
with separate compilation. If I have the above in a header, then in one
compilation unit:
template<typename T> {
  void foo(T param) { do something with param; }
  void bar(T param) { do something with param; }
}

something() {
foo(3);
}

It feels natural if I instantiate any one of these on an explicit type, I
should be able to link against any of them. I don't think that's a
reasonable assumption, but natural enough that it could lead to
confusion.Using the same name but with a syntax that clearly denotes
independence is a very different form implicit relation, and I think easier
to explain.

--
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 email 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/CAJH_FNVebzbcf-iME1unNM8MNEx2TtEnJCRtXamz769TReqYGw%40mail.gmail.com.

--94eb2c054954905bb6054eb51f59
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I like the class namespace proposal. I&#39;ve often wished=
 for such a thing as a clean way of separating interface from implementatio=
n in template code.<div><br></div><div>I&#39;m a little less keen on this p=
roposal because I share the concern that when I see:</div><div>template&lt;=
typename T&gt; {</div><div>=C2=A0 void foo(T param);</div><div>=C2=A0 void =
bar(T param);</div><div>}</div><div><br></div><div>My brain wants to assume=
 that those Ts are the same.=C2=A0</div><div><br></div><div>Whether that ma=
tters is open to question, and depends substantially on whether such a fact=
 would ever be expected to be visible. It may matter with separate compilat=
ion. If I have the above in a header, then in one compilation unit:</div><d=
iv><div>template&lt;typename T&gt; {</div><div>=C2=A0 void foo(T param) { d=
o something with param; }</div><div>=C2=A0=C2=A0void bar(T param) { do some=
thing with param; }</div><div>}</div></div><div><br></div><div>something() =
{</div><div>foo(3);</div><div>}</div><div><br></div><div>It feels natural i=
f I instantiate any one of these on an explicit type, I should be able to l=
ink against any of them. I don&#39;t think that&#39;s a reasonable assumpti=
on, but natural enough that it could lead to confusion.Using the same name =
but with a syntax that clearly denotes independence is a very different for=
m implicit relation, and I think easier to explain.=C2=A0</div><div><br></d=
iv><div><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJH_FNVebzbcf-iME1unNM8MNEx2TtEnJCRt=
Xamz769TReqYGw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJH_FNVebzbcf-iM=
E1unNM8MNEx2TtEnJCRtXamz769TReqYGw%40mail.gmail.com</a>.<br />

--94eb2c054954905bb6054eb51f59--

.

I see what you mean. I don't actually have a good comeback for this
concern. Unless... unless this would make the two functions be
instantiated together or not at all. But probably that's going a bit too
far. I dunno, I guess it's a foil then.

On 04/05/17 18:18, Lee Howes wrote:
> I like the class namespace proposal. I've often wished for such a thing
> as a clean way of separating interface from implementation in template code.
>
> I'm a little less keen on this proposal because I share the concern that
> when I see:
> template<typename T> {
>   void foo(T param);
>   void bar(T param);
> }
>
> My brain wants to assume that those Ts are the same.
>
> Whether that matters is open to question, and depends substantially on
> whether such a fact would ever be expected to be visible. It may matter
> with separate compilation. If I have the above in a header, then in one
> compilation unit:
> template<typename T> {
>   void foo(T param) { do something with param; }
>   void bar(T param) { do something with param; }
> }
>
> something() {
> foo(3);
> }
>
> It feels natural if I instantiate any one of these on an explicit type,
> I should be able to link against any of them. I don't think that's a
> reasonable assumption, but natural enough that it could lead to
> confusion.Using the same name but with a syntax that clearly denotes
> independence is a very different form implicit relation, and I think
> easier to explain.
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/1c8_Fa3Rj44/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org
> <mailto:std-proposals@isocpp.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJH_FNVebzbcf-iME1unNM8MNEx2TtEnJCRtXamz769TReqYGw%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJH_FNVebzbcf-iME1unNM8MNEx2TtEnJCRtXamz769TReqYGw%40mail.gmail.com?utm_medium=email&utm_source=footer>.

--
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 email 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/b909e7d9-8caf-9ba0-602c-57e968f0af2b%40technion.ac.il.

.