------=_Part_1718_9219898.1357409223686
Content-Type: text/plain; charset=ISO-8859-1

I wonder if anyone feels the same as me about using declaration while
specifying members from base class? As things are now, it is very blunt and
not very precise tool, which could be quite easily tweaked.
What I mean is:

class A
{
public:
void f();
void f(int);
};

class B: public A
{
using A::f;//here we cannot make a choice on which one we would like to use
in our B class, which sometimes is ok...
};

but in scenario:
class A
{
void f(int);
public:
void f();
};

class B :public A
{
using A::f;//will not compile even though the only fnc we want is A::f()
};

What I would like to propose is following backwards compatible syntax:

class B :public A
{
using A::f;//here I'm specifying that I want use every fnc 'f' from A -
just like before, but this will not compile
using A::f();//here I explicitly specify which fnc I want to use
};

The use case which is I believe compelling is the one that if function f
overloaded and one or more is declared  private, this actively prohibits us
from the use of any other, non-private functions 'f' from the base class.

Looking forward to comments.

--




------=_Part_1718_9219898.1357409223686
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I wonder if anyone feels the same as me about using declaration while speci=
fying members from base class? As things are now, it is very blunt and not =
very precise tool, which could be quite easily tweaked.<div>What I mean is:=
</div><div><br></div><div>class A</div><div>{</div><div>public:</div><div>v=
oid f();</div><div>void f(int);</div><div>};<br></div><div><br></div><div>c=
lass B: public A</div><div>{</div><div>using A::f;//here we cannot make a c=
hoice on which one we would like to use in our B class, which sometimes is =
ok...</div><div>};</div><div><br></div><div>but in scenario:</div><div>clas=
s A</div><div>{</div><div>void f(int);</div><div>public:</div><div>void f()=
;</div><div>};</div><div><br></div><div>class B :public A</div><div>{</div>=
<div>using A::f;//will not compile even though the only fnc we want is A::f=
()</div><div>};</div><div><br></div><div>What I would like to propose is fo=
llowing backwards compatible syntax:</div><div><br></div><div><div>class B =
:public A</div><div>{</div><div>using A::f;//here I'm specifying that I wan=
t use every fnc 'f' from A - just like before, but this will not compile</d=
iv><div>using A::f();//here I explicitly specify which fnc I want to use</d=
iv><div>};</div></div><div><br></div><div>The use case which is I believe&n=
bsp;compelling is the one that if function f overloaded and one or more is =
declared&nbsp;&nbsp;private, this actively prohibits us from the use of any=
 other, non-private functions 'f' from the base class.</div><div><br></div>=
<div>Looking forward to comments.</div><div><br></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1718_9219898.1357409223686--

.

On 5 January 2013 20:07, Arthur Tchaikovsky <atch.cpp@gmail.com> wrote:
> I wonder if anyone feels the same as me about using declaration while
> specifying members from base class? As things are now, it is very blunt and
> not very precise tool, which could be quite easily tweaked.
> What I mean is:
> class A
> {
> public:
> void f();
> void f(int);
> };
> class B: public A
> {
> using A::f;//here we cannot make a choice on which one we would like to use
> in our B class, which sometimes is ok...
> };
> but in scenario:
> class A
> {
> void f(int);
> public:
> void f();
> };
> class B :public A
> {
> using A::f;//will not compile even though the only fnc we want is A::f()
> };
> What I would like to propose is following backwards compatible syntax:
> class B :public A
> {
> using A::f;//here I'm specifying that I want use every fnc 'f' from A - just
> like before, but this will not compile
> using A::f();//here I explicitly specify which fnc I want to use
> };
> The use case which is I believe compelling is the one that if function f
> overloaded and one or more is declared  private, this actively prohibits us
> from the use of any other, non-private functions 'f' from the base class.
> Looking forward to comments.

The work-around would, I think, be

class B :public A
{
   void f(int x) {A::f(x);}
};

Adding the new syntax doesn't seem to be compelling compared to the
very low cost
of specifying exactly the signatures you want and calling the base
implementation of them.

--




.

------=_Part_2014_5742179.1357593486946
Content-Type: text/plain; charset=ISO-8859-1



On Monday, January 7, 2013 11:08:05 AM UTC-8, Ville Voutilainen wrote:
>
> On 5 January 2013 20:07, Arthur Tchaikovsky <atch...@gmail.com<javascript:>>
> wrote:
> > I wonder if anyone feels the same as me about using declaration while
> > specifying members from base class? As things are now, it is very blunt
> and
> > not very precise tool, which could be quite easily tweaked.
> > What I mean is:
> > class A
> > {
> > public:
> > void f();
> > void f(int);
> > };
> > class B: public A
> > {
> > using A::f;//here we cannot make a choice on which one we would like to
> use
> > in our B class, which sometimes is ok...
> > };
> > but in scenario:
> > class A
> > {
> > void f(int);
> > public:
> > void f();
> > };
> > class B :public A
> > {
> > using A::f;//will not compile even though the only fnc we want is A::f()
> > };
> > What I would like to propose is following backwards compatible syntax:
> > class B :public A
> > {
> > using A::f;//here I'm specifying that I want use every fnc 'f' from A -
> just
> > like before, but this will not compile
> > using A::f();//here I explicitly specify which fnc I want to use
> > };
> > The use case which is I believe compelling is the one that if function f
> > overloaded and one or more is declared  private, this actively prohibits
> us
> > from the use of any other, non-private functions 'f' from the base
> class.
> > Looking forward to comments.
>
> The work-around would, I think, be
>
> class B :public A
> {
>    void f(int x) {A::f(x);}
> };
>
> Adding the new syntax doesn't seem to be compelling compared to the
> very low cost
> of specifying exactly the signatures you want and calling the base
> implementation of them.
>

It's not as maintainable. If the syntax in `A` changes, you don't get a
proper compiler error if the syntax happens to remain compatible with the
old one. If they change `f(int)` to `f(int64_t)` or something, the compiler
will silently let this work.

With the proposed syntax, if there is no `f(int)` in the base class, it
fails to compile. Which forces everyone to update to the new syntax. It's
also a lot more obvious what's going on.

--




------=_Part_2014_5742179.1357593486946
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Monday, January 7, 2013 11:08:05 AM UTC-8, Ville Voutilainen wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;">On 5 January 2013 20:07, Ar=
thur Tchaikovsky &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscat=
ed-mailto=3D"OcIk-eH-UNwJ">atch...@gmail.com</a>&gt; wrote:
<br>&gt; I wonder if anyone feels the same as me about using declaration wh=
ile
<br>&gt; specifying members from base class? As things are now, it is very =
blunt and
<br>&gt; not very precise tool, which could be quite easily tweaked.
<br>&gt; What I mean is:
<br>&gt; class A
<br>&gt; {
<br>&gt; public:
<br>&gt; void f();
<br>&gt; void f(int);
<br>&gt; };
<br>&gt; class B: public A
<br>&gt; {
<br>&gt; using A::f;//here we cannot make a choice on which one we would li=
ke to use
<br>&gt; in our B class, which sometimes is ok...
<br>&gt; };
<br>&gt; but in scenario:
<br>&gt; class A
<br>&gt; {
<br>&gt; void f(int);
<br>&gt; public:
<br>&gt; void f();
<br>&gt; };
<br>&gt; class B :public A
<br>&gt; {
<br>&gt; using A::f;//will not compile even though the only fnc we want is =
A::f()
<br>&gt; };
<br>&gt; What I would like to propose is following backwards compatible syn=
tax:
<br>&gt; class B :public A
<br>&gt; {
<br>&gt; using A::f;//here I'm specifying that I want use every fnc 'f' fro=
m A - just
<br>&gt; like before, but this will not compile
<br>&gt; using A::f();//here I explicitly specify which fnc I want to use
<br>&gt; };
<br>&gt; The use case which is I believe compelling is the one that if func=
tion f
<br>&gt; overloaded and one or more is declared &nbsp;private, this activel=
y prohibits us
<br>&gt; from the use of any other, non-private functions 'f' from the base=
 class.
<br>&gt; Looking forward to comments.
<br>
<br>The work-around would, I think, be
<br>
<br>class B :public A
<br>{
<br>&nbsp; &nbsp;void f(int x) {A::f(x);}
<br>};
<br>
<br>Adding the new syntax doesn't seem to be compelling compared to the
<br>very low cost
<br>of specifying exactly the signatures you want and calling the base
<br>implementation of them.
<br></blockquote><div><br>It's not as maintainable. If the syntax in `A` ch=
anges, you don't get a proper compiler error if the syntax happens to remai=
n compatible with the old one. If they change `f(int)` to `f(int64_t)` or s=
omething, the compiler will silently let this work.<br><br>With the propose=
d syntax, if there is no `f(int)` in the base class, it fails to compile. W=
hich forces everyone to update to the new syntax. It's also a lot more obvi=
ous what's going on.<br></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_2014_5742179.1357593486946--

.

On 7 January 2013 23:18, Nicol Bolas <jmckesson@gmail.com> wrote:
>> The work-around would, I think, be
>> class B :public A
>> {
>>    void f(int x) {A::f(x);}
>> };
> It's not as maintainable. If the syntax in `A` changes, you don't get a
> proper compiler error if the syntax happens to remain compatible with the
> old one. If they change `f(int)` to `f(int64_t)` or something, the compiler
> will silently let this work.

Fine, a further work-around is to add another statement that gets a
pointer to the base member, that'll fail
to compile if the type of the argument in the base changes.

> With the proposed syntax, if there is no `f(int)` in the base class, it
> fails to compile. Which forces everyone to update to the new syntax. It's
> also a lot more obvious what's going on.

It's also yet another rule that is different from the existing
using-declaration. The existing
using-declaration will silently accept compatible calls (with implicit
conversions, unfortunately),
this new one wouldn't. I don't think it would be an improvement major
enough to matter.
I think it would be useful, but for quite narrow amounts of cases, and
I don't think the
use case is compelling enough to warrant an extension.

--




.

------=_Part_1720_30086527.1357603164529
Content-Type: text/plain; charset=ISO-8859-1

On Monday, January 7, 2013 1:30:28 PM UTC-8, Ville Voutilainen wrote:
>
> On 7 January 2013 23:18, Nicol Bolas <jmck...@gmail.com <javascript:>>
> wrote:
> >> The work-around would, I think, be
> >> class B :public A
> >> {
> >>    void f(int x) {A::f(x);}
> >> };
> > It's not as maintainable. If the syntax in `A` changes, you don't get a
> > proper compiler error if the syntax happens to remain compatible with
> the
> > old one. If they change `f(int)` to `f(int64_t)` or something, the
> compiler
> > will silently let this work.
>
> Fine, a further work-around is to add another statement that gets a
> pointer to the base member, that'll fail
> to compile if the type of the argument in the base changes.
>

Now that's just getting esoteric. While this is not exactly a hugely common
use case, it's not exactly vanishingly rare either. A user shouldn't have
to do an unintuitive operation like getting a member pointer just to be
able to decide which functions to inherit and which not to.

That's like saying we shouldn't bother with the `= delete` syntax because
we can just declare the member private.

> With the proposed syntax, if there is no `f(int)` in the base class, it
> > fails to compile. Which forces everyone to update to the new syntax.
> It's
> > also a lot more obvious what's going on.
>
> It's also yet another rule that is different from the existing
> using-declaration. The existing
> using-declaration will silently accept compatible calls (with implicit
> conversions, unfortunately),
> this new one wouldn't. I don't think it would be an improvement major
> enough to matter.
> I think it would be useful, but for quite narrow amounts of cases, and
> I don't think the
> use case is compelling enough to warrant an extension.
>

Thinking like this is what makes me want the C++ committee to establish
some kind of "small feature" group. It's for things that are too small to
warrant serious attention, but not minor editorial changes. What makes a
language "smooth" isn't the big features; it's the little features. Those
things you either use every day, or that one wart you run into just
frequently enough to be annoying. `= delete` syntax is kind of like that.

I'm talking about the sorts of things that, in languages not designed by
committee, would be what some open-source developer implements himself and
just submits a patch for.

This feature, as defined above, is:

1: Safe. It doesn't affect backwards compatibility in any way, nor does it
have any obvious breakages or affects on other language features.

2: Solves a problem that certainly exists.

3: Makes the language smoother.

Good, useful, and safe features should never be relegated to the "too small
to bother with" bin.

--




------=_Part_1720_30086527.1357603164529
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Monday, January 7, 2013 1:30:28 PM UTC-8, Ville Voutilainen wrote:<block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;">On 7 January 2013 23:18, Nicol Bolas=
 &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"RP8=
IktUvhSEJ">jmck...@gmail.com</a>&gt; wrote:
<br>&gt;&gt; The work-around would, I think, be
<br>&gt;&gt; class B :public A
<br>&gt;&gt; {
<br>&gt;&gt; &nbsp; &nbsp;void f(int x) {A::f(x);}
<br>&gt;&gt; };
<br>&gt; It's not as maintainable. If the syntax in `A` changes, you don't =
get a
<br>&gt; proper compiler error if the syntax happens to remain compatible w=
ith the
<br>&gt; old one. If they change `f(int)` to `f(int64_t)` or something, the=
 compiler
<br>&gt; will silently let this work.
<br>
<br>Fine, a further work-around is to add another statement that gets a
<br>pointer to the base member, that'll fail
<br>to compile if the type of the argument in the base changes.<br></blockq=
uote><div><br>Now that's just getting esoteric. While this is not exactly a=
 hugely common use case, it's not exactly vanishingly rare either. A user s=
houldn't have to do an unintuitive operation like getting a member pointer =
just to be able to decide which functions to inherit and which not to.<br><=
br>That's like saying we shouldn't bother with the `=3D delete` syntax beca=
use we can just declare the member private.<br><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">&gt; With the proposed syntax, if there is no `=
f(int)` in the base class, it
<br>&gt; fails to compile. Which forces everyone to update to the new synta=
x. It's
<br>&gt; also a lot more obvious what's going on.
<br>
<br>It's also yet another rule that is different from the existing
<br>using-declaration. The existing
<br>using-declaration will silently accept compatible calls (with implicit
<br>conversions, unfortunately),
<br>this new one wouldn't. I don't think it would be an improvement major
<br>enough to matter.
<br>I think it would be useful, but for quite narrow amounts of cases, and
<br>I don't think the
<br>use case is compelling enough to warrant an extension.<br></blockquote>=
<div><br>Thinking like this is what makes me want the C++ committee to esta=
blish some kind of "small feature" group. It's for things that are too smal=
l to warrant serious attention, but not minor editorial changes. What makes=
 a language "smooth" isn't the big features; it's the little features. Thos=
e things you either use every day, or that one wart you run into just frequ=
ently enough to be annoying. `=3D delete` syntax is kind of like that.<br><=
br>I'm talking about the sorts of things that, in languages not designed by=
 committee, would be what some open-source developer implements himself and=
 just submits a patch for.<br><br>This feature, as defined above, is:<br><b=
r>1: Safe. It doesn't affect backwards compatibility in any way, nor does i=
t have any obvious breakages or affects on other language features.<br><br>=
2: Solves a problem that certainly exists.<br><br>3: Makes the language smo=
other.<br><br>Good, useful, and safe features should never be relegated to =
the "too small to bother with" bin.<br></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1720_30086527.1357603164529--

.

On 8 January 2013 01:59, Nicol Bolas <jmckesson@gmail.com> wrote:
>> > old one. If they change `f(int)` to `f(int64_t)` or something, the
>> > compiler
>> > will silently let this work.
>> Fine, a further work-around is to add another statement that gets a
>> pointer to the base member, that'll fail
>> to compile if the type of the argument in the base changes.
> Now that's just getting esoteric. While this is not exactly a hugely common

Indeed it is. Wanting a compiler error when a function signature is changed in
a safe and compatible manner is indeed esoteric. ;)

> use case, it's not exactly vanishingly rare either. A user shouldn't have to
> do an unintuitive operation like getting a member pointer just to be able to
> decide which functions to inherit and which not to.

Then don't. Define the overloads you need and call the base if that is suitable.

> That's like saying we shouldn't bother with the `= delete` syntax because we
> can just declare the member private.

That's hardly the same thing, as other members and friends can still
call a private
member function.

> Thinking like this is what makes me want the C++ committee to establish some
> kind of "small feature" group. It's for things that are too small to warrant

That would likely be beneficial both on the language and the library
side of things.
We're trying to collect such "tiny" issues, it remains to be seen
whether we'll actually
succeed. Part of if depends on my getting off my lazy arse and
creating an evolution
issue list, but there are things like a day job that hinder such activities.

--




.

------=_Part_791_17842400.1357635265371
Content-Type: text/plain; charset=ISO-8859-1

>Thinking like this is what makes me want the C++ committee to establish
some
>kind of "small feature" group.

I believe that this would work really great and C++ could only benefit from
it.

On Saturday, 5 January 2013 18:07:03 UTC, Arthur Tchaikovsky wrote:
>
> I wonder if anyone feels the same as me about using declaration while
> specifying members from base class? As things are now, it is very blunt and
> not very precise tool, which could be quite easily tweaked.
> What I mean is:
>
> class A
> {
> public:
> void f();
> void f(int);
> };
>
> class B: public A
> {
> using A::f;//here we cannot make a choice on which one we would like to
> use in our B class, which sometimes is ok...
> };
>
> but in scenario:
> class A
> {
> void f(int);
> public:
> void f();
> };
>
> class B :public A
> {
> using A::f;//will not compile even though the only fnc we want is A::f()
> };
>
> What I would like to propose is following backwards compatible syntax:
>
> class B :public A
> {
> using A::f;//here I'm specifying that I want use every fnc 'f' from A -
> just like before, but this will not compile
> using A::f();//here I explicitly specify which fnc I want to use
> };
>
> The use case which is I believe compelling is the one that if function f
> overloaded and one or more is declared  private, this actively prohibits us
> from the use of any other, non-private functions 'f' from the base class.
>
> Looking forward to comments.
>
>

--




------=_Part_791_17842400.1357635265371
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<span style=3D"color: rgb(80, 0, 80);">&gt;Thinking like this is what makes=
 me want the C++ committee to establish some&nbsp;</span><br style=3D"color=
: rgb(80, 0, 80);"><span style=3D"color: rgb(80, 0, 80);">&gt;kind of "smal=
l feature" group.</span><div><br></div><div><font color=3D"#500050">I belie=
ve that this would work really great and C++ could only benefit from it.</f=
ont></div><div><br>On Saturday, 5 January 2013 18:07:03 UTC, Arthur Tchaiko=
vsky  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I wonder if anyone=
 feels the same as me about using declaration while specifying members from=
 base class? As things are now, it is very blunt and not very precise tool,=
 which could be quite easily tweaked.<div>What I mean is:</div><div><br></d=
iv><div>class A</div><div>{</div><div>public:</div><div>void f();</div><div=
>void f(int);</div><div>};<br></div><div><br></div><div>class B: public A</=
div><div>{</div><div>using A::f;//here we cannot make a choice on which one=
 we would like to use in our B class, which sometimes is ok...</div><div>};=
</div><div><br></div><div>but in scenario:</div><div>class A</div><div>{</d=
iv><div>void f(int);</div><div>public:</div><div>void f();</div><div>};</di=
v><div><br></div><div>class B :public A</div><div>{</div><div>using A::f;//=
will not compile even though the only fnc we want is A::f()</div><div>};</d=
iv><div><br></div><div>What I would like to propose is following backwards =
compatible syntax:</div><div><br></div><div><div>class B :public A</div><di=
v>{</div><div>using A::f;//here I'm specifying that I want use every fnc 'f=
' from A - just like before, but this will not compile</div><div>using A::f=
();//here I explicitly specify which fnc I want to use</div><div>};</div></=
div><div><br></div><div>The use case which is I believe&nbsp;compelling is =
the one that if function f overloaded and one or more is declared&nbsp;&nbs=
p;private, this actively prohibits us from the use of any other, non-privat=
e functions 'f' from the base class.</div><div><br></div><div>Looking forwa=
rd to comments.</div><div><br></div></blockquote></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_791_17842400.1357635265371--

.

On Tue, Jan 8, 2013 at 3:54 AM, Arthur Tchaikovsky <atch.cpp@gmail.com> wrote:
>>Thinking like this is what makes me want the C++ committee to establish
>> some
>>kind of "small feature" group.
>
> I believe that this would work really great and C++ could only benefit from
> it.

The C++ committee is an all volunteer organization. That's true for
both technical work and administrative work. The committee needs more
volunteers for admin work like keeping a "small features" tracking
list up-to-date. Ditto for a "library proposals" tracking list.

You don't have to attend every meeting to volunteer. Several valued
admin volunteers attend meetings when they can (i.e. only European
meetings or North American meetings, where their travel costs are
reasonable) and otherwise participate electronically via the
committee's private mailing lists and wikis.

The next committee meeting is Bristol, UK, April 15-20. The fall
meeting will be in Chicago, IL, USA.

Bottom line: If you want something to happen, volunteer to make it happen!

--Beman

--




.

------=_Part_89_31754920.1357666333572
Content-Type: text/plain; charset=ISO-8859-1

Where shall I sign? ;)
I am more than happy to volunteer and be of any use. And as I love C++ I
believe that I'll be happy to do this work.

On Tuesday, 8 January 2013 15:39:21 UTC, Beman Dawes wrote:
>
> On Tue, Jan 8, 2013 at 3:54 AM, Arthur Tchaikovsky <atch...@gmail.com<javascript:>>
> wrote:
> >>Thinking like this is what makes me want the C++ committee to establish
> >> some
> >>kind of "small feature" group.
> >
> > I believe that this would work really great and C++ could only benefit
> from
> > it.
>
> The C++ committee is an all volunteer organization. That's true for
> both technical work and administrative work. The committee needs more
> volunteers for admin work like keeping a "small features" tracking
> list up-to-date. Ditto for a "library proposals" tracking list.
>
> You don't have to attend every meeting to volunteer. Several valued
> admin volunteers attend meetings when they can (i.e. only European
> meetings or North American meetings, where their travel costs are
> reasonable) and otherwise participate electronically via the
> committee's private mailing lists and wikis.
>
> The next committee meeting is Bristol, UK, April 15-20. The fall
> meeting will be in Chicago, IL, USA.
>
> Bottom line: If you want something to happen, volunteer to make it happen!
>
> --Beman
>

--




------=_Part_89_31754920.1357666333572
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Where shall I sign? ;)<div>I am more than happy to volunteer and be of any =
use. And as I love C++ I believe that I'll be happy to do this work.<br><br=
>On Tuesday, 8 January 2013 15:39:21 UTC, Beman Dawes  wrote:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;">On Tue, Jan 8, 2013 at 3:54 AM, Arthur Tchai=
kovsky &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"iFX0sGfaM2sJ">atch...@gmail.com</a>&gt; wrote:
<br>&gt;&gt;Thinking like this is what makes me want the C++ committee to e=
stablish
<br>&gt;&gt; some
<br>&gt;&gt;kind of "small feature" group.
<br>&gt;
<br>&gt; I believe that this would work really great and C++ could only ben=
efit from
<br>&gt; it.
<br>
<br>The C++ committee is an all volunteer organization. That's true for
<br>both technical work and administrative work. The committee needs more
<br>volunteers for admin work like keeping a "small features" tracking
<br>list up-to-date. Ditto for a "library proposals" tracking list.
<br>
<br>You don't have to attend every meeting to volunteer. Several valued
<br>admin volunteers attend meetings when they can (i.e. only European
<br>meetings or North American meetings, where their travel costs are
<br>reasonable) and otherwise participate electronically via the
<br>committee's private mailing lists and wikis.
<br>
<br>The next committee meeting is Bristol, UK, April 15-20. The fall
<br>meeting will be in Chicago, IL, USA.
<br>
<br>Bottom line: If you want something to happen, volunteer to make it happ=
en!
<br>
<br>--Beman
<br></blockquote></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_89_31754920.1357666333572--

.

------=_Part_2268_82902.1357700717381
Content-Type: text/plain; charset=ISO-8859-1

I've mentioned it briefly once before on this list (several months ago)
that I have a similar idea that would include something like this but in a
larger context of function aliasing.

When the using-keyword is used to change the accessibility of a base type's
member, it is like we are creating an alias in the current type's scope for
the base type's member.  I'd like to generalize that idea to allow for the
following types of things

   - defining a simple forwarding function (pass each parameter onto either
   a base method or a method of a member
   - mapping the interface for one type to the interface of another
   (similar to concept maps, but less "concepty")
   - optionally allowing parameter reordering for forwarding functions
   - using methods from a base class A to satisfy the virtual method
   requirements from a second base class B
   - making it easier to swap out implementations for free-standing
   functions (similar to type name aliasing tricks)
   - perhaps eliminating the practice of using function pointers for
   aliasing where the pointed-to-function is known at compile-time and never
   changes.

I believe that Nicol's concerns about changing interfaces is real (I've
seen it happen), and is in fact one of the driving forces behind the
final/override syntax for polymorphic types.  This would bring that same
capability to non-virtual types (perhaps even with similar syntax)  Ville's
example of a forwarding function is a simple (but common) one.  There are
"nastier" examples in real-world code though.

I'm not quite ready to begin an official proposal document for these ideas,
but would be more than willing to partner with others that might be
interested.  I'd guess that minus the technical specifications,
incorporating all of these ideas would be a rather lengthy proposal and I
would also consider breaking it into smaller ones if it helped get any
piece through the standardization process.

On Saturday, January 5, 2013 12:07:03 PM UTC-6, Arthur Tchaikovsky wrote:
>
> I wonder if anyone feels the same as me about using declaration while
> specifying members from base class? As things are now, it is very blunt and
> not very precise tool, which could be quite easily tweaked.
> What I mean is:
>
> class A
> {
> public:
> void f();
> void f(int);
> };
>
> class B: public A
> {
> using A::f;//here we cannot make a choice on which one we would like to
> use in our B class, which sometimes is ok...
> };
>
> but in scenario:
> class A
> {
> void f(int);
> public:
> void f();
> };
>
> class B :public A
> {
> using A::f;//will not compile even though the only fnc we want is A::f()
> };
>
> What I would like to propose is following backwards compatible syntax:
>
> class B :public A
> {
> using A::f;//here I'm specifying that I want use every fnc 'f' from A -
> just like before, but this will not compile
> using A::f();//here I explicitly specify which fnc I want to use
> };
>
> The use case which is I believe compelling is the one that if function f
> overloaded and one or more is declared  private, this actively prohibits us
> from the use of any other, non-private functions 'f' from the base class.
>
> Looking forward to comments.
>
>

--




------=_Part_2268_82902.1357700717381
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I've mentioned it briefly once before on this list (several months ago) tha=
t I have a similar idea that would include something like this but in a lar=
ger context of function aliasing.<div><br></div><div>When the using-keyword=
 is used to change the accessibility of a base type's member, it is like we=
 are creating an alias in the current type's scope for the base type's memb=
er. &nbsp;I'd like to generalize that idea to allow for the following types=
 of things</div><div><ul><li>defining a simple forwarding function (pass ea=
ch parameter onto either a base method or a method of a member<br></li><li>=
mapping the interface for one type to the interface of another (similar to =
concept maps, but less "concepty")<br></li><li>optionally allowing paramete=
r reordering for forwarding functions<br></li><li>using methods from a base=
 class A to satisfy the virtual method requirements from a second base clas=
s B<br></li><li>making it easier to swap out implementations for free-stand=
ing functions (similar to type name aliasing tricks)</li><li>perhaps elimin=
ating the practice of using function pointers for aliasing where the pointe=
d-to-function is known at compile-time and never changes.</li></ul></div><d=
iv>I believe that Nicol's concerns about changing interfaces is real (I've =
seen it happen), and is in fact one of the driving forces behind the final/=
override syntax for polymorphic types. &nbsp;This would bring that same cap=
ability to non-virtual types (perhaps even with similar syntax) &nbsp;Ville=
's example of a forwarding function is a simple (but common) one. &nbsp;The=
re are "nastier" examples in real-world code though.</div><div><br></div><d=
iv>I'm not quite ready to begin an official proposal document for these ide=
as, but would be more than willing to partner with others that might be int=
erested. &nbsp;I'd guess that minus the technical specifications, incorpora=
ting all of these ideas would be a rather lengthy proposal and I would also=
 consider breaking it into smaller ones if it helped get any piece through =
the standardization process.</div><div><br>On Saturday, January 5, 2013 12:=
07:03 PM UTC-6, Arthur Tchaikovsky wrote:<blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;">I wonder if anyone feels the same as me about using declaration =
while specifying members from base class? As things are now, it is very blu=
nt and not very precise tool, which could be quite easily tweaked.<div>What=
 I mean is:</div><div><br></div><div>class A</div><div>{</div><div>public:<=
/div><div>void f();</div><div>void f(int);</div><div>};<br></div><div><br><=
/div><div>class B: public A</div><div>{</div><div>using A::f;//here we cann=
ot make a choice on which one we would like to use in our B class, which so=
metimes is ok...</div><div>};</div><div><br></div><div>but in scenario:</di=
v><div>class A</div><div>{</div><div>void f(int);</div><div>public:</div><d=
iv>void f();</div><div>};</div><div><br></div><div>class B :public A</div><=
div>{</div><div>using A::f;//will not compile even though the only fnc we w=
ant is A::f()</div><div>};</div><div><br></div><div>What I would like to pr=
opose is following backwards compatible syntax:</div><div><br></div><div><d=
iv>class B :public A</div><div>{</div><div>using A::f;//here I'm specifying=
 that I want use every fnc 'f' from A - just like before, but this will not=
 compile</div><div>using A::f();//here I explicitly specify which fnc I wan=
t to use</div><div>};</div></div><div><br></div><div>The use case which is =
I believe&nbsp;compelling is the one that if function f overloaded and one =
or more is declared&nbsp;&nbsp;private, this actively prohibits us from the=
 use of any other, non-private functions 'f' from the base class.</div><div=
><br></div><div>Looking forward to comments.</div><div><br></div></blockquo=
te></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_2268_82902.1357700717381--

.

On Tue, Jan 8, 2013 at 12:32 PM, Arthur Tchaikovsky <atch.cpp@gmail.com> wrote:
> Where shall I sign? ;)

See http://isocpp.org/std/meetings-and-participation

It is very common to start out by attending a meeting or two before
actually signing up with your national body, and thus becoming a
member. Also note that there are several mechanisms available for
folks from a country that doesn't have a "national body" or has a NB
that charges more money than an individual can afford.

You can contact me privately for information about meeting venues, etc.

> I am more than happy to volunteer and be of any use. And as I love C++ I
> believe that I'll be happy to do this work.

:-)

--Beman

--




.