------=_Part_182_1771004435.1445250587998
Content-Type: multipart/alternative;
 boundary="----=_Part_183_310458972.1445250587998"

------=_Part_183_310458972.1445250587998
Content-Type: text/plain; charset=UTF-8

I'm not sure whether any such issue already appeared.

It is sometimes desirable that during the call one may want to use some
special symbols that are meaningful for the function being called.

Some people use simply boolean values to indicate something, but this is
generally a discouraged practice, as at the place of the call it's rarely
clear as to what particular "true" or "false" argument means for particular
call.

Therefore it's better to use some symbolic names. These, however have to be
defined globally and therefore pollute the namespace of both the caller and
the definition. For example:

class Block
{
      ...
      void Move(size_t how_many, Direction direction);
};

We have currently the following possibilities:

1. Direction = bool, then we have:
   block.Move( 10, true ); // true means up, maybe it's clear for some
people...

2. Direction is an enum inside Block:
   block.Move( 10, Block::DIR_UP );  // a little bit clumsy, especially if
you haven't imported the namespace

3. Direction is an enum outside Block:
   block.Move( 10, DIR_UP); // looks good, but it pollutes the whole
namespace with DIR_UP and the others

The problem with solution #3 is that it causes that a class that just needs
some symbols for its own use, introduces them for the whole namespace and
causes potential conflicts with other similar ones.

Desired are two things:

1. Allow for importing a namespace not only of namespaces, but also classes
for their static definitions:

   using class Block; // that is, allow to use static symbols defined
inside Block without the classname:: prefix.
   block.Move( 10, DIR_UP ); // in the local context, the same as
Block::DIR_UP

2. Some syntax that allows to distinguish between the symbol in the current
namespace and a symbol in a namespace of a class that provides the method
being called:

  block.Move( 10, .DIR_UP ); // " .DIR_UP " means " Block::DIR_UP " because
this Move method is a method of Block class

Of course, this local symbol resolution should regard only the static
definitions. That is, if 'block' was accidentally a reference to a class
that is base for Block, it won't be understood as Block::DIR_UP, whereas
when this is a class that derives from Block, the enum with these symbols
will be derived as all other parts.

What do you think?

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_183_310458972.1445250587998
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I&#39;m not sure whether any such issue already appeared.<=
br><br>It is sometimes desirable that during the call one may want to use s=
ome special symbols that are meaningful for the function being called.<br><=
br>Some people use simply boolean values to indicate something, but this is=
 generally a discouraged practice, as at the place of the call it&#39;s rar=
ely clear as to what particular &quot;true&quot; or &quot;false&quot; argum=
ent means for particular call.<br><br>Therefore it&#39;s better to use some=
 symbolic names. These, however have to be defined globally and therefore p=
ollute the namespace of both the caller and the definition. For example:<br=
><br>class Block<br>{<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ...<br>=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 void Move(size_t how_many, Direction direction);<br>};<b=
r><br>We have currently the following possibilities:<br><br>1. Direction =
=3D bool, then we have:<br>=C2=A0=C2=A0 block.Move( 10, true ); // true mea=
ns up, maybe it&#39;s clear for some people...<br><br>2. Direction is an en=
um inside Block:<br>=C2=A0=C2=A0 block.Move( 10, Block::DIR_UP );=C2=A0 // =
a little bit clumsy, especially if you haven&#39;t imported the namespace<b=
r><br>3. Direction is an enum outside Block:<br>=C2=A0=C2=A0 block.Move( 10=
, DIR_UP); // looks good, but it pollutes the whole namespace with DIR_UP a=
nd the others<br><br>The problem with solution #3 is that it causes that a =
class that just needs some symbols for its own use, introduces them for the=
 whole namespace and causes potential conflicts with other similar ones.<br=
><br>Desired are two things:<br><br>1. Allow for importing a namespace not =
only of namespaces, but also classes for their static definitions:<br><br>=
=C2=A0=C2=A0 using class Block; // that is, allow to use static symbols def=
ined inside Block without the classname:: prefix.<br>=C2=A0=C2=A0 block.Mov=
e( 10, DIR_UP ); // in the local context, the same as Block::DIR_UP<br><br>=
2. Some syntax that allows to distinguish between the symbol in the current=
 namespace and a symbol in a namespace of a class that provides the method =
being called:<br><br>=C2=A0 block.Move( 10, .DIR_UP ); // &quot; .DIR_UP &q=
uot; means &quot; Block::DIR_UP &quot; because this Move method is a method=
 of Block class<br><br>Of course, this local symbol resolution should regar=
d only the static definitions. That is, if &#39;block&#39; was accidentally=
 a reference to a class that is base for Block, it won&#39;t be understood =
as Block::DIR_UP, whereas when this is a class that derives from Block, the=
 enum with these symbols will be derived as all other parts.<br><br>What do=
 you think?<br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_183_310458972.1445250587998--
------=_Part_182_1771004435.1445250587998--

.

On 2015-10-19 06:29, ethouris@gmail.com wrote:
> I'm not sure whether any such issue already appeared.

It has, though I don't have a reference offhand to the previous discussion.

> It is sometimes desirable that during the call one may want to use some
> special symbols that are meaningful for the function being called.
>
> Some people use simply boolean values to indicate something, but this is
> generally a discouraged practice, as at the place of the call it's rarely
> clear as to what particular "true" or "false" argument means for particular
> call.
>
> Therefore it's better to use some symbolic names. These, however have to be
> defined globally and therefore pollute the namespace of both the caller and
> the definition.

There were mutterings along these lines:

  int foo(enum { A, B } opt)
  {
    if (opt == A) // okay; 'A' is in scope for this function
    ...
  }

  foo(A); // okay, parameters use 'foo's scope for name lookup

....with some mechanism desired to name 'A' outside of the body or call
site of 'foo'.

I don't recall what ever became of it.

> Desired are two things:
>
> 1. Allow for importing a namespace not only of namespaces, but also classes
> for their static definitions:
>
>    using class Block; // that is, allow to use static symbols defined
> inside Block without the classname:: prefix.
>    block.Move( 10, DIR_UP ); // in the local context, the same as
> Block::DIR_UP

You don't need this. What you need is to be able to use a 'using'
declaration to bring the values of an enum (especially an enum class)
into another scope. For various reasons; not just your example. (You'd
potentially have to do this for multiple enums, but that's more
surgical, and therefore safer, than dragging in the members for the
entire class.)

> 2. Some syntax that allows to distinguish between the symbol in the current
> namespace and a symbol in a namespace of a class that provides the method
> being called:
>
>   block.Move( 10, .DIR_UP ); // " .DIR_UP " means " Block::DIR_UP " because
> this Move method is a method of Block class

See above.

--
Matthew

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_3602_1107841106.1445345514645
Content-Type: multipart/alternative;
 boundary="----=_Part_3603_855290204.1445345514645"

------=_Part_3603_855290204.1445345514645
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



W dniu poniedzia=C5=82ek, 19 pa=C5=BAdziernika 2015 17:47:51 UTC+2 u=C5=BCy=
tkownik Matthew=20
Woehlke napisa=C5=82:
>
> There were mutterings along these lines:=20
>
>   int foo(enum { A, B } opt)=20
>   {=20
>     if (opt =3D=3D A) // okay; 'A' is in scope for this function=20
>     ...=20
>   }=20
>
>   foo(A); // okay, parameters use 'foo's scope for name lookup=20
>
> ...with some mechanism desired to name 'A' outside of the body or call=20
> site of 'foo'.=20
>

That's not exactly my proposal.
=20

>
> > 2. Some syntax that allows to distinguish between the symbol in the=20
> current=20
> > namespace and a symbol in a namespace of a class that provides the=20
> method=20
> > being called:=20
> >=20
> >   block.Move( 10, .DIR_UP ); // " .DIR_UP " means " Block::DIR_UP "=20
> because=20
> > this Move method is a method of Block class=20
>
> See above.=20
>

Above you don't have DOT before the name.

The intention of this proposal is to be able to DISTINGUISH (as I have=20
explicitly declared) between a symbol from the scope of the current=20
function and the scope of the current, say, context:

block.Move( 10, DIR_UP ); // available in the overall namespace
sprintf(x, "up=3D%d", int(DIR_UP)); // also for other functions

vs.

block.Move( 10, .DIR_UP ); // available only in the namespace of the called=
=20
function (the class of Move method in this case)
sprintf(x, "up=3D%d", int(.DIR_UP)); // ERROR: sprintf doesn't have any loc=
al=20
symbol named "DIR_UP"

The intent of using a special syntax for that is because the readability of=
=20
the code may decrease and it may lead to confusion if you just use the=20
symbol name in this function. People usually expect that if a symbol name=
=20
is used, then it's the symbol from the surrounding namespace, and not from=
=20
some local context of the function being called.


=20
=20

>
> --=20
> Matthew=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_3603_855290204.1445345514645
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>W dniu poniedzia=C5=82ek, 19 pa=C5=BAdziernika 201=
5 17:47:51 UTC+2 u=C5=BCytkownik Matthew Woehlke napisa=C5=82:<blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
 #ccc solid;padding-left: 1ex;">There were mutterings along these lines:
<br>
<br>=C2=A0 int foo(enum { A, B } opt)
<br>=C2=A0 {
<br>=C2=A0 =C2=A0 if (opt =3D=3D A) // okay; &#39;A&#39; is in scope for th=
is function
<br>=C2=A0 =C2=A0 ...
<br>=C2=A0 }
<br>
<br>=C2=A0 foo(A); // okay, parameters use &#39;foo&#39;s scope for name lo=
okup
<br>
<br>...with some mechanism desired to name &#39;A&#39; outside of the body =
or call
<br>site of &#39;foo&#39;.
<br></blockquote><div><br>That&#39;s not exactly my proposal.<br>=C2=A0</di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;">
<br>&gt; 2. Some syntax that allows to distinguish between the symbol in th=
e current=20
<br>&gt; namespace and a symbol in a namespace of a class that provides the=
 method=20
<br>&gt; being called:
<br>&gt;=20
<br>&gt; =C2=A0 block.Move( 10, .DIR_UP ); // &quot; .DIR_UP &quot; means &=
quot; Block::DIR_UP &quot; because=20
<br>&gt; this Move method is a method of Block class
<br>
<br>See above.
<br></blockquote><div><br>Above you don&#39;t have DOT before the name.<br>=
<br>The
 intention of this proposal is to be able to DISTINGUISH (as I have=20
explicitly declared) between a symbol from the scope of the current=20
function and the scope of the current, say, context:<br><br>block.Move( 10,=
 DIR_UP ); // available in the overall namespace<br>sprintf(x, &quot;up=3D%=
d&quot;, int(DIR_UP)); // also for other functions<br><br>vs.<br><br>block.=
Move( 10, .DIR_UP ); // available only in the namespace of the called funct=
ion (the class of Move method in this case)<br>sprintf(x, &quot;up=3D%d&quo=
t;, int(.DIR_UP)); // ERROR: sprintf doesn&#39;t have any local symbol name=
d &quot;DIR_UP&quot;<br><br>The
 intent of using a special syntax for that is because the readability of
 the code may decrease and it may lead to confusion if you just use the=20
symbol name in this function. People usually expect that if a symbol name i=
s used, then it&#39;s the symbol from the surrounding namespace, and not fr=
om some local context of the function being called.<br><br><br>=C2=A0<br></=
div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>--=20
<br>Matthew
<br>
<br></blockquote></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_3603_855290204.1445345514645--
------=_Part_3602_1107841106.1445345514645--

.

On 2015-10-20 08:51, ethouris@gmail.com wrote:
> W dniu poniedzia=C5=82ek, 19 pa=C5=BAdziernika 2015 17:47:51 UTC+2 u=C5=
=BCytkownik Matthew=20
> Woehlke napisa=C5=82:
>>
>> There were mutterings along these lines:=20
>>
>>   int foo(enum { A, B } opt)=20
>>   {=20
>>     if (opt =3D=3D A) // okay; 'A' is in scope for this function=20
>>     ...=20
>>   }=20
>>
>>   foo(A); // okay, parameters use 'foo's scope for name lookup=20
>>
>> ...with some mechanism desired to name 'A' outside of the body or call=
=20
>> site of 'foo'.=20
>=20
> That's not exactly my proposal.

The point was to bring to your attention what has been discussed
previously. In particular, note the suggestion to have *function* local
enums.

I think the sensible thing to do would be to allow name lookup for a
parameter to use the "namespace" of the parameter type (or all possible
parameter types, in the case of overloads). Overloads make this a little
tricky and potentially introduce ambiguities, but I think it's possible
to implement. This would not depend on, and could be useful without,
function-scope enums (although the converse is not true).

> Above you don't have DOT before the name.

I don't recall specifically if any such similar qualification was
suggested previously (see again above comment). My own personal
inclination would be to omit it. I'm not necessarily *strongly* opposed
to it, either, but for the above proposed lookup rule, I'm not sure how
much sense it makes (as the context could be arbitrary). For example:

  class Foo
  {
    enum class Bar { FooA, ... };
    void foo(Bar);
  };
  void free_function(Foo::Bar);

  Foo f;
  f.foo(FooA); // okay
  free_function(FooA); // also okay
  sqrt(int{FooA}); // error

(OTOH, it's conceivable that not qualifying it in some novel way could
break existing code, so...)

--=20
Matthew

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.