Topic: Implicit lookup for enum-members in the right namespace.
Author: DerAlbi <thealbig@gmail.com>
Date: Sun, 21 May 2017 06:23:29 -0700 (PDT)
Raw View
------=_Part_2102_86098400.1495373009156
Content-Type: multipart/alternative;
boundary="----=_Part_2103_1798248136.1495373009156"
------=_Part_2103_1798248136.1495373009156
Content-Type: text/plain; charset="UTF-8"
Hi guys,
enums are a handy way to describe typesafe magic values in C++ or to define
descriptive parameters.
However they sit within the namespace they are declared in which may become
too crowded way too fast.
One solution is to declare enums within a class or namespace - so you have
class specific enums which makes sence if a class is handling a specific
subset of functionality so you only may need the enums there anyway.
So...
struct MyClass
{
enum MyEnum { A, B, C, D };
void DoSomething(const MyEnum Enum)
{
//
}
};
void Function(MyClass& Class)
{
Class.DoSomething(MyClass::A); // Current way to access the enum
Class.DoSomething(B); // New way to access the enum?
}
See, the compiler knows that an enum of type MyClass::MyEnum is expected,
to why would i need to write MyClass:: everywhere? The compiler can
implicitly lookup within this namespace first without abiguity.
It is most likely that A,B.. and so on are descriptive enough that the
whole Function call makes a valid reading without the MyClass::.
Such language functionality would need clarification what happens if there
is a variable called exactly like an enum member - i guess this should
throw a warning and may be decided on lvalue vs rvalue usage.
MyClass:MyEnum A = A; // variable A is asigned MyClass:MyEnum::A - please
throw a warning. (That A is the symbol here can be deduced from context
again)
Class.DoSomething(A) // in this case the variable should be used, not the
Symbol.
Another problematic situation is:
void Function(MyClass& Class)
{
enum MyEnum { A, B, C, D };
Class.DoSomething(MyClass::A); // Current way to access the enum
Class.DoSomething(B); // Which B is used? The right one of course - the
B that machtes the type thats requested.
Class.DoSomething(MyClass::MyEnum(::B)); // if you want to use the
other B, use :: to escape from the inplicit namespace lookup
}
I hope this is worth a thought. This would diminish the need for longer
than necessary enum symbols and may even make for an easier read most of
the time.
You could use enum { Low, High }; everywhere and the context could be
implicitly dedurced. So...
Waterlevel = High;
Pin = High;
is typesafe and ok.. better than
Waterlevel = Ocean::High;
Pin = PinClass::High;
or even
Waterlevel = Ocean_High;
Pin = PinClass_High;
if you want to overcrowd your namespace.
--
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/7e67a951-1b08-4ace-8f8d-a7192ae460ee%40isocpp.org.
------=_Part_2103_1798248136.1495373009156
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi guys,<br><br>enums are a handy way to describe typesafe=
magic values in C++ or to define descriptive parameters. <br>However they =
sit within the namespace they are declared in which may become too crowded =
way too fast. <br>One solution is to declare enums within a class or namesp=
ace - so you have class specific enums which makes sence if a class is hand=
ling a specific subset of functionality so you only may need the enums ther=
e anyway.<br><br>So...<br><br>struct MyClass<br>{<br>=C2=A0=C2=A0=C2=A0 enu=
m MyEnum=C2=A0 { A, B, C, D };<br>=C2=A0=C2=A0=C2=A0 void DoSomething(const=
MyEnum Enum)<br>=C2=A0=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=
=A0 =C2=A0=C2=A0=C2=A0 //<br>=C2=A0=C2=A0=C2=A0 }<br>};<br><br>void Functio=
n(MyClass& Class)<br>{<br>=C2=A0=C2=A0=C2=A0 Class.DoSomething(MyClass:=
:A); // Current way to access the enum<br>=C2=A0=C2=A0=C2=A0 Class.DoSometh=
ing(B); // New way to access the enum?<br>}<br><br>See, the compiler knows =
that an enum of type MyClass::MyEnum is expected, to why would i need to wr=
ite MyClass:: everywhere? The compiler can implicitly lookup within this na=
mespace first without abiguity.<br>It is most likely that A,B.. and so on a=
re descriptive enough that the whole Function call makes a valid reading wi=
thout the MyClass::.=C2=A0 <br><br>Such language functionality would need c=
larification what happens if there is a variable called exactly like an enu=
m member - i guess this should throw a warning and may be decided on lvalue=
vs rvalue usage.<br><br>MyClass:MyEnum A =3D A; // variable A is asigned M=
yClass:MyEnum::A - please throw a warning.=C2=A0 (That A is the symbol here=
can be deduced from context again)<br>Class.DoSomething(A) // in this case=
the variable should be used, not the Symbol.<br><br>Another problematic si=
tuation is:<br><br>void Function(MyClass& Class)<br>{<br>=C2=A0=C2=A0=
=C2=A0 enum MyEnum=C2=A0 { A, B, C, D }; <br>=C2=A0 =C2=A0 Class.DoSomethin=
g(MyClass::A); // Current way to access the enum<br>=C2=A0=C2=A0=C2=A0 Clas=
s.DoSomething(B); // Which B is used? The right one of course - the B that =
machtes the type thats requested.<br>=C2=A0=C2=A0=C2=A0 Class.DoSomething(M=
yClass::MyEnum(::B)); // if you want to use the other B, use :: to escape f=
rom the inplicit namespace lookup<br><br>}<br><br><br>I hope this is worth =
a thought. This would diminish the need for longer than necessary enum symb=
ols and may even make for an easier read most of the time.<br>You could use=
enum { Low, High }; everywhere and the context could be implicitly dedurce=
d. So...<br><br>Waterlevel =3D High;<br>Pin =3D High; <br><br>is typesafe a=
nd ok.. better than<br><br>Waterlevel =3D Ocean::High;<br>Pin =3D PinClass:=
:High;<br><br>or even<br><br>Waterlevel =3D Ocean_High;<br>Pin =3D PinClass=
_High;<br><br>if you want to overcrowd your namespace.<br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/7e67a951-1b08-4ace-8f8d-a7192ae460ee%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7e67a951-1b08-4ace-8f8d-a7192ae460ee=
%40isocpp.org</a>.<br />
------=_Part_2103_1798248136.1495373009156--
------=_Part_2102_86098400.1495373009156--
.
Author: Ibrahim Timothy Onogu <tionogu@gmail.com>
Date: Sun, 21 May 2017 17:09:32 +0100
Raw View
--001a11378912e2d22a05500afa55
Content-Type: text/plain; charset="UTF-8"
Are you still using pre-C++11 standard in your compiler?
Are you saying you haven't heard of, or used strongly typed enums? 'enum
class'?
This feature has been in C++ for many years now (since C++11)...
On Sunday, May 21, 2017, DerAlbi <thealbig@gmail.com> wrote:
> Hi guys,
>
> enums are a handy way to describe typesafe magic values in C++ or to
define descriptive parameters.
> However they sit within the namespace they are declared in which may
become too crowded way too fast.
> One solution is to declare enums within a class or namespace - so you
have class specific enums which makes sence if a class is handling a
specific subset of functionality so you only may need the enums there
anyway.
>
> So...
>
> struct MyClass
> {
> enum MyEnum { A, B, C, D };
> void DoSomething(const MyEnum Enum)
> {
> //
> }
> };
>
> void Function(MyClass& Class)
> {
> Class.DoSomething(MyClass::A); // Current way to access the enum
> Class.DoSomething(B); // New way to access the enum?
> }
>
> See, the compiler knows that an enum of type MyClass::MyEnum is expected,
to why would i need to write MyClass:: everywhere? The compiler can
implicitly lookup within this namespace first without abiguity.
> It is most likely that A,B.. and so on are descriptive enough that the
whole Function call makes a valid reading without the MyClass::.
>
> Such language functionality would need clarification what happens if
there is a variable called exactly like an enum member - i guess this
should throw a warning and may be decided on lvalue vs rvalue usage.
>
> MyClass:MyEnum A = A; // variable A is asigned MyClass:MyEnum::A - please
throw a warning. (That A is the symbol here can be deduced from context
again)
> Class.DoSomething(A) // in this case the variable should be used, not the
Symbol.
>
> Another problematic situation is:
>
> void Function(MyClass& Class)
> {
> enum MyEnum { A, B, C, D };
> Class.DoSomething(MyClass::A); // Current way to access the enum
> Class.DoSomething(B); // Which B is used? The right one of course -
the B that machtes the type thats requested.
> Class.DoSomething(MyClass::MyEnum(::B)); // if you want to use the
other B, use :: to escape from the inplicit namespace lookup
>
> }
>
>
> I hope this is worth a thought. This would diminish the need for longer
than necessary enum symbols and may even make for an easier read most of
the time.
> You could use enum { Low, High }; everywhere and the context could be
implicitly dedurced. So...
>
> Waterlevel = High;
> Pin = High;
>
> is typesafe and ok.. better than
>
> Waterlevel = Ocean::High;
> Pin = PinClass::High;
>
> or even
>
> Waterlevel = Ocean_High;
> Pin = PinClass_High;
>
> if you want to overcrowd your namespace.
>
> --
> 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/7e67a951-1b08-4ace-8f8d-a7192ae460ee%40isocpp.org
..
>
--
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/CA%2BzGKGZ0uhM4Am5tSE-q3oQJDd6kC0Cn%2BV6EUaBmR3a-XMQRCQ%40mail.gmail.com.
--001a11378912e2d22a05500afa55
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Are you still using pre-C++11 standard in your compiler?<br><br>Are you say=
ing you haven't heard of, or used strongly typed enums? 'enum class=
'?<br><br>This feature has been in C++ for many years now (since C++11)=
....<br><br><br><br>On Sunday, May 21, 2017, DerAlbi <<a href=3D"mailto:t=
healbig@gmail.com">thealbig@gmail.com</a>> wrote:<br>> Hi guys,<br>&g=
t;<br>> enums are a handy way to describe typesafe magic values in C++ o=
r to define descriptive parameters.<br>> However they sit within the nam=
espace they are declared in which may become too crowded way too fast.<br>&=
gt; One solution is to declare enums within a class or namespace - so you h=
ave class specific enums which makes sence if a class is handling a specifi=
c subset of functionality so you only may need the enums there anyway.<br>&=
gt;<br>> So...<br>><br>> struct MyClass<br>> {<br>> =C2=A0=
=C2=A0=C2=A0 enum MyEnum=C2=A0 { A, B, C, D };<br>> =C2=A0=C2=A0=C2=A0 v=
oid DoSomething(const MyEnum Enum)<br>> =C2=A0=C2=A0=C2=A0 {<br>> =C2=
=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 //<br>> =C2=A0=C2=
=A0=C2=A0 }<br>> };<br>><br>> void Function(MyClass& Class)<br=
>> {<br>> =C2=A0=C2=A0=C2=A0 Class.DoSomething(MyClass::A); // Curren=
t way to access the enum<br>> =C2=A0=C2=A0=C2=A0 Class.DoSomething(B); /=
/ New way to access the enum?<br>> }<br>><br>> See, the compiler k=
nows that an enum of type MyClass::MyEnum is expected, to why would i need =
to write MyClass:: everywhere? The compiler can implicitly lookup within th=
is namespace first without abiguity.<br>> It is most likely that A,B.. a=
nd so on are descriptive enough that the whole Function call makes a valid =
reading without the MyClass::.=C2=A0<br>><br>> Such language function=
ality would need clarification what happens if there is a variable called e=
xactly like an enum member - i guess this should throw a warning and may be=
decided on lvalue vs rvalue usage.<br>><br>> MyClass:MyEnum A =3D A;=
// variable A is asigned MyClass:MyEnum::A - please throw a warning.=C2=A0=
(That A is the symbol here can be deduced from context again)<br>> Clas=
s.DoSomething(A) // in this case the variable should be used, not the Symbo=
l.<br>><br>> Another problematic situation is:<br>><br>> void F=
unction(MyClass& Class)<br>> {<br>> =C2=A0=C2=A0=C2=A0 enum MyEnu=
m=C2=A0 { A, B, C, D };<br>> =C2=A0 =C2=A0 Class.DoSomething(MyClass::A)=
; // Current way to access the enum<br>> =C2=A0=C2=A0=C2=A0 Class.DoSome=
thing(B); // Which B is used? The right one of course - the B that machtes =
the type thats requested.<br>> =C2=A0=C2=A0=C2=A0 Class.DoSomething(MyCl=
ass::MyEnum(::B)); // if you want to use the other B, use :: to escape from=
the inplicit namespace lookup<br>><br>> }<br>><br>><br>> I =
hope this is worth a thought. This would diminish the need for longer than =
necessary enum symbols and may even make for an easier read most of the tim=
e.<br>> You could use enum { Low, High }; everywhere and the context cou=
ld be implicitly dedurced. So...<br>><br>> Waterlevel =3D High;<br>&g=
t; Pin =3D High;<br>><br>> is typesafe and ok.. better than<br>><b=
r>> Waterlevel =3D Ocean::High;<br>> Pin =3D PinClass::High;<br>><=
br>> or even<br>><br>> Waterlevel =3D Ocean_High;<br>> Pin =3D =
PinClass_High;<br>><br>> if you want to overcrowd your namespace.<br>=
><br>> --<br>> You received this message because you are subscribe=
d to the Google Groups "ISO C++ Standard - Future Proposals" grou=
p.<br>> To unsubscribe from this group and stop receiving emails from it=
, send an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org=
">std-proposals+unsubscribe@isocpp.org</a>.<br>> To post to this group, =
send email to <a href=3D"mailto:std-proposals@isocpp.org">std-proposals@iso=
cpp.org</a>.<br>> To view this discussion on the web visit <a href=3D"ht=
tps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7e67a951-1b08-4a=
ce-8f8d-a7192ae460ee%40isocpp.org">https://groups.google.com/a/isocpp.org/d=
/msgid/std-proposals/7e67a951-1b08-4ace-8f8d-a7192ae460ee%40isocpp.org</a>.=
<br>>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CA%2BzGKGZ0uhM4Am5tSE-q3oQJDd6kC0Cn%2=
BV6EUaBmR3a-XMQRCQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BzGKGZ0uh=
M4Am5tSE-q3oQJDd6kC0Cn%2BV6EUaBmR3a-XMQRCQ%40mail.gmail.com</a>.<br />
--001a11378912e2d22a05500afa55--
.
Author: =?UTF-8?Q?Daniel_Kr=C3=BCgler?= <daniel.kruegler@gmail.com>
Date: Sun, 21 May 2017 18:25:54 +0200
Raw View
2017-05-21 18:09 GMT+02:00 Ibrahim Timothy Onogu <tionogu@gmail.com>:
> Are you still using pre-C++11 standard in your compiler?
>
> Are you saying you haven't heard of, or used strongly typed enums? 'enum
> class'?
>
> This feature has been in C++ for many years now (since C++11)...
Please read more carefully what the OP was suggesting, before claiming
such things. It has nothing to do with existing C++ lookup rules,
neither C++11 nor C++14. I'm not saying that I wish to have the
suggested changes, but it is definitively not an already existing one.
- Daniel
--
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/CAGNvRgDgwnbYeiFNYe-5yq%2BKGDV%2B64kXzU83zgyWB-oUvTX9Nw%40mail.gmail.com.
.
Author: Ibrahim Timothy Onogu <tionogu@gmail.com>
Date: Sun, 21 May 2017 17:38:49 +0100
Raw View
--f4030435b804a39b3b05500b63f0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
I just reread it. I'm sorry DerAlbi,
Thank you for drawing my attention to that, Daniel.
I clearly misunderstood it.
Regards,
Timothy
On Sun, May 21, 2017 at 5:25 PM, Daniel Kr=C3=BCgler <daniel.kruegler@gmail=
..com>
wrote:
> 2017-05-21 18:09 GMT+02:00 Ibrahim Timothy Onogu <tionogu@gmail.com>:
> > Are you still using pre-C++11 standard in your compiler?
> >
> > Are you saying you haven't heard of, or used strongly typed enums? 'enu=
m
> > class'?
> >
> > This feature has been in C++ for many years now (since C++11)...
>
> Please read more carefully what the OP was suggesting, before claiming
> such things. It has nothing to do with existing C++ lookup rules,
> neither C++11 nor C++14. I'm not saying that I wish to have the
> suggested changes, but it is definitively not an already existing one.
>
> - Daniel
>
> --
> 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/CAGNvRgDgwnbYeiFNYe-
> 5yq%2BKGDV%2B64kXzU83zgyWB-oUvTX9Nw%40mail.gmail.com.
>
--=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/CA%2BzGKGZJ9o1Fbz--EAuEOcYyFsMARnN6YRy_LPi_XXc04=
O%2BqgQ%40mail.gmail.com.
--f4030435b804a39b3b05500b63f0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I just reread it. I'm sorry DerAlbi,<br></div><di=
v>Thank you for drawing my attention to that, Daniel.<br>I clearly misunder=
stood it.<br><br><br></div><div>Regards,<br></div><div>Timothy<br></div></d=
iv><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sun, May 21=
, 2017 at 5:25 PM, Daniel Kr=C3=BCgler <span dir=3D"ltr"><<a href=3D"mai=
lto:daniel.kruegler@gmail.com" target=3D"_blank">daniel.kruegler@gmail.com<=
/a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">20=
17-05-21 18:09 GMT+02:00 Ibrahim Timothy Onogu <<a href=3D"mailto:tionog=
u@gmail.com">tionogu@gmail.com</a>>:<br>
> Are you still using pre-C++11 standard in your compiler?<br>
><br>
> Are you saying you haven't heard of, or used strongly typed enums?=
'enum<br>
> class'?<br>
><br>
> This feature has been in C++ for many years now (since C++11)...<br>
<br>
</span>Please read more carefully what the OP was suggesting, before claimi=
ng<br>
such things. It has nothing to do with existing C++ lookup rules,<br>
neither C++11 nor C++14. I'm not saying that I wish to have the<br>
suggested changes, but it is definitively not an already existing one.<br>
<br>
- Daniel<br>
<span class=3D""><br>
--<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@<wbr>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>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/CAGNvRgDgwnbYeiFNYe-5yq%2BKGDV=
%2B64kXzU83zgyWB-oUvTX9Nw%40mail.gmail.com" rel=3D"noreferrer" target=3D"_b=
lank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposal=
s/CAGNvRgDgwnbYeiFNYe-<wbr>5yq%2BKGDV%2B64kXzU83zgyWB-<wbr>oUvTX9Nw%40mail.=
gmail.com</a>.<br>
</blockquote></div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CA%2BzGKGZJ9o1Fbz--EAuEOcYyFsMARnN6YR=
y_LPi_XXc04O%2BqgQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BzGKGZJ9o=
1Fbz--EAuEOcYyFsMARnN6YRy_LPi_XXc04O%2BqgQ%40mail.gmail.com</a>.<br />
--f4030435b804a39b3b05500b63f0--
.
Author: =?UTF-8?Q?Daniel_Kr=C3=BCgler?= <daniel.kruegler@gmail.com>
Date: Sun, 21 May 2017 18:55:05 +0200
Raw View
2017-05-21 15:23 GMT+02:00 DerAlbi <thealbig@gmail.com>:
> Hi guys,
>
> enums are a handy way to describe typesafe magic values in C++ or to define
> descriptive parameters.
> However they sit within the namespace they are declared in which may become
> too crowded way too fast.
One should be cautious with such an assertion, since these scopes are
valuable as well, since they reduce the risk of ambiguities.
> One solution is to declare enums within a class or namespace - so you have
> class specific enums which makes sence if a class is handling a specific
> subset of functionality so you only may need the enums there anyway.
>
> So...
>
> struct MyClass
> {
> enum MyEnum { A, B, C, D };
> void DoSomething(const MyEnum Enum)
> {
> //
> }
> };
>
> void Function(MyClass& Class)
> {
> Class.DoSomething(MyClass::A); // Current way to access the enum
> Class.DoSomething(B); // New way to access the enum?
> }
Consider a slight variant of this:
struct MyClass
{
enum MyEnum { A, B, C, D };
void DoSomething(const MyEnum Enum)
{
//
}
};
MyClass::MyEnum B = MyClass::MyEnum::B;
void Function(MyClass& Class)
{
Class.DoSomething(MyClass::A); // Current way to access the enum
Class.DoSomething(B); // Ambuiguity?
}
Would this now cause an ambiguity?
Here a variation of the same theme:
struct MyClass
{
enum MyEnum { A, B, C, D };
void DoSomething(const MyEnum Enum)
{
//
}
};
struct Other
{
operator MyClass::MyEnum() const;
} B;
void Function(MyClass& Class)
{
Class.DoSomething(MyClass::A); // Current way to access the enum
Class.DoSomething(B); // Ambuiguity?
}
> See, the compiler knows that an enum of type MyClass::MyEnum is expected, to
> why would i need to write MyClass:: everywhere? The compiler can implicitly
> lookup within this namespace first without abiguity.
See the examples above where (without any extra-rules involved) an
ambiguity would occur or I would not know how to realize the original
(current) meaning.
> It is most likely that A,B.. and so on are descriptive enough that the whole
> Function call makes a valid reading without the MyClass::.
>
> Such language functionality would need clarification what happens if there
> is a variable called exactly like an enum member - i guess this should throw
> a warning and may be decided on lvalue vs rvalue usage.
The warning does not solve the programming problem.
> MyClass:MyEnum A = A; // variable A is asigned MyClass:MyEnum::A - please
> throw a warning. (That A is the symbol here can be deduced from context
> again)
> Class.DoSomething(A) // in this case the variable should be used, not the
> Symbol.
>
> Another problematic situation is:
>
> void Function(MyClass& Class)
> {
> enum MyEnum { A, B, C, D };
> Class.DoSomething(MyClass::A); // Current way to access the enum
> Class.DoSomething(B); // Which B is used? The right one of course - the
> B that machtes the type thats requested.
> Class.DoSomething(MyClass::MyEnum(::B)); // if you want to use the other
> B, use :: to escape from the inplicit namespace lookup
>
> }
>
>
> I hope this is worth a thought. This would diminish the need for longer than
> necessary enum symbols and may even make for an easier read most of the
> time.
IMO it is not worth it unless you give a way to the programmer to
resolve the ambiguity to either the one or the other direction. In
particular your suggestion would silently change the meaning of
existing programs without making them ill-formed which is one of the
worst kind of problems.
I would be more sympathetic with your proposal if it would would
suggest to provide a kind of using declaration such as the following:
struct MyClass
{
enum MyEnum { A, B, C, D };
void DoSomething(const MyEnum Enum)
{
//
}
};
void Function(MyClass& Class)
{
Class.DoSomething(MyClass::A); // Current way to access the enum
using MyClass::B;
// using MyClass::MyEnum to provide access to all enumerators.
Class.DoSomething(B); // New way to access the enum?
}
- Daniel
--
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/CAGNvRgC8ex8C%2BELnX_7y%3Dd%3DkgrHqpf%2Bw%2BZxX24DR3OJXH4S9xw%40mail.gmail.com.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 21 May 2017 10:41:39 -0700 (PDT)
Raw View
------=_Part_2133_591984265.1495388499328
Content-Type: multipart/alternative;
boundary="----=_Part_2134_587964710.1495388499328"
------=_Part_2134_587964710.1495388499328
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Sunday, May 21, 2017 at 12:55:08 PM UTC-4, Daniel Kr=C3=BCgler wrote:
>
> 2017-05-21 15:23 GMT+02:00 DerAlbi <thea...@gmail.com <javascript:>>:=20
> > Hi guys,=20
> >=20
> > enums are a handy way to describe typesafe magic values in C++ or to=20
> define=20
> > descriptive parameters.=20
> > However they sit within the namespace they are declared in which may=20
> become=20
> > too crowded way too fast.=20
>
> One should be cautious with such an assertion, since these scopes are=20
> valuable as well, since they reduce the risk of ambiguities.=20
>
> > One solution is to declare enums within a class or namespace - so you=
=20
> have=20
> > class specific enums which makes sence if a class is handling a specifi=
c=20
> > subset of functionality so you only may need the enums there anyway.=20
> >=20
> > So...=20
> >=20
> > struct MyClass=20
> > {=20
> > enum MyEnum { A, B, C, D };=20
> > void DoSomething(const MyEnum Enum)=20
> > {=20
> > //=20
> > }=20
> > };=20
> >=20
> > void Function(MyClass& Class)=20
> > {=20
> > Class.DoSomething(MyClass::A); // Current way to access the enum=20
> > Class.DoSomething(B); // New way to access the enum?=20
> > }=20
>
> Consider a slight variant of this:=20
>
> struct MyClass=20
> {=20
> enum MyEnum { A, B, C, D };=20
> void DoSomething(const MyEnum Enum)=20
> {=20
> //=20
> }=20
> };=20
>
> MyClass::MyEnum B =3D MyClass::MyEnum::B;=20
>
> void Function(MyClass& Class)=20
> {=20
> Class.DoSomething(MyClass::A); // Current way to access the enum=20
> Class.DoSomething(B); // Ambuiguity?=20
> }=20
>
> Would this now cause an ambiguity?=20
>
> Here a variation of the same theme:=20
>
> struct MyClass=20
> {=20
> enum MyEnum { A, B, C, D };=20
> void DoSomething(const MyEnum Enum)=20
> {=20
> //=20
> }=20
> };=20
>
> struct Other=20
> {=20
> operator MyClass::MyEnum() const;=20
> } B;=20
>
> void Function(MyClass& Class)=20
> {=20
> Class.DoSomething(MyClass::A); // Current way to access the enum=20
> Class.DoSomething(B); // Ambuiguity?=20
> }=20
>
> > See, the compiler knows that an enum of type MyClass::MyEnum is=20
> expected, to=20
> > why would i need to write MyClass:: everywhere? The compiler can=20
> implicitly=20
> > lookup within this namespace first without abiguity.=20
>
> See the examples above where (without any extra-rules involved) an=20
> ambiguity would occur or I would not know how to realize the original=20
> (current) meaning.=20
>
> > It is most likely that A,B.. and so on are descriptive enough that the=
=20
> whole=20
> > Function call makes a valid reading without the MyClass::.=20
> >=20
> > Such language functionality would need clarification what happens if=20
> there=20
> > is a variable called exactly like an enum member - i guess this should=
=20
> throw=20
> > a warning and may be decided on lvalue vs rvalue usage.=20
>
> The warning does not solve the programming problem.=20
>
> > MyClass:MyEnum A =3D A; // variable A is asigned MyClass:MyEnum::A -=20
> please=20
> > throw a warning. (That A is the symbol here can be deduced from contex=
t=20
> > again)=20
> > Class.DoSomething(A) // in this case the variable should be used, not=
=20
> the=20
> > Symbol.=20
> >=20
> > Another problematic situation is:=20
> >=20
> > void Function(MyClass& Class)=20
> > {=20
> > enum MyEnum { A, B, C, D };=20
> > Class.DoSomething(MyClass::A); // Current way to access the enum=20
> > Class.DoSomething(B); // Which B is used? The right one of course -=
=20
> the=20
> > B that machtes the type thats requested.=20
> > Class.DoSomething(MyClass::MyEnum(::B)); // if you want to use the=
=20
> other=20
> > B, use :: to escape from the inplicit namespace lookup=20
> >=20
> > }=20
> >=20
> >=20
> > I hope this is worth a thought. This would diminish the need for longer=
=20
> than=20
> > necessary enum symbols and may even make for an easier read most of the=
=20
> > time.=20
>
> IMO it is not worth it unless you give a way to the programmer to=20
> resolve the ambiguity to either the one or the other direction. In=20
> particular your suggestion would silently change the meaning of=20
> existing programs without making them ill-formed which is one of the=20
> worst kind of problems.=20
>
> I would be more sympathetic with your proposal if it would would=20
> suggest to provide a kind of using declaration such as the following:=20
>
> struct MyClass=20
> {=20
> enum MyEnum { A, B, C, D };=20
> void DoSomething(const MyEnum Enum)=20
> {=20
> //=20
> }=20
> };=20
>
> void Function(MyClass& Class)=20
> {=20
> Class.DoSomething(MyClass::A); // Current way to access the enum=20
> using MyClass::B;=20
> // using MyClass::MyEnum to provide access to all enumerators.=20
> Class.DoSomething(B); // New way to access the enum?=20
> }=20
>
But that makes the proposal rather pointless. The whole idea is to make the=
=20
short and obvious code do the obvious thing. If you have to have every=20
function where you're calling these things qualified with a `using`=20
declaration, then you're just making the code longer in a different way.
Now, I don't agree with the proposal. But your suggestion doesn't really=20
achieve the goal that the proposal is trying to achieve.
Not only that, you can't exactly stick a `using` directive in a default=20
member initializer or a member initialization list. Or in various other=20
places. Also, `using` directives have a tendency to leak, so you can't just=
=20
stick them in a file header somewhere. So it lack the universal nature of=
=20
the original.
If the problem is deciding between whether an identifier is meant to be a=
=20
variable name or an enumerator name, then perhaps that's something we could=
=20
resolve. We simply need to apply some qualification to the name to tell the=
=20
compiler that this is an enumerator and we want to resolve the actual=20
enumerator it based on the context. We could employ a symbol or a keyword=
=20
to do so. `.enumerator` or `enum enumerator`, perhaps. The latter is a bit=
=20
long, but it's generally longer than most namespaces and/or class names.
--=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/657ec96a-10f7-4b31-bf22-3961b81cddc2%40isocpp.or=
g.
------=_Part_2134_587964710.1495388499328
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sunday, May 21, 2017 at 12:55:08 PM UTC-4, Daniel Kr=C3=
=BCgler wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">2017-05-21 15:23=
GMT+02:00 DerAlbi <<a href=3D"javascript:" target=3D"_blank" gdf-obfusc=
ated-mailto=3D"J_4ZMtl5AwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#=
39;javascript:';return true;" onclick=3D"this.href=3D'javascript:&#=
39;;return true;">thea...@gmail.com</a>>:
<br>> Hi guys,
<br>>
<br>> enums are a handy way to describe typesafe magic values in C++ or =
to define
<br>> descriptive parameters.
<br>> However they sit within the namespace they are declared in which m=
ay become
<br>> too crowded way too fast.
<br>
<br>One should be cautious with such an assertion, since these scopes are
<br>valuable as well, since they reduce the risk of ambiguities.
<br>
<br>> One solution is to declare enums within a class or namespace - so =
you have
<br>> class specific enums which makes sence if a class is handling a sp=
ecific
<br>> subset of functionality so you only may need the enums there anywa=
y.
<br>>
<br>> So...
<br>>
<br>> struct MyClass
<br>> {
<br>> =C2=A0 =C2=A0 enum MyEnum =C2=A0{ A, B, C, D };
<br>> =C2=A0 =C2=A0 void DoSomething(const MyEnum Enum)
<br>> =C2=A0 =C2=A0 {
<br>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 //
<br>> =C2=A0 =C2=A0 }
<br>> };
<br>>
<br>> void Function(MyClass& Class)
<br>> {
<br>> =C2=A0 =C2=A0 Class.DoSomething(MyClass::A); // Current way to acc=
ess the enum
<br>> =C2=A0 =C2=A0 Class.DoSomething(B); // New way to access the enum?
<br>> }
<br>
<br>Consider a slight variant of this:
<br>
<br>struct MyClass
<br>{
<br>=C2=A0 =C2=A0 enum MyEnum =C2=A0{ A, B, C, D };
<br>=C2=A0 =C2=A0 void DoSomething(const MyEnum Enum)
<br>=C2=A0 =C2=A0 {
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 //
<br>=C2=A0 =C2=A0 }
<br>};
<br>
<br>MyClass::MyEnum B =3D MyClass::MyEnum::B;
<br>
<br>void Function(MyClass& Class)
<br>{
<br>=C2=A0 =C2=A0 Class.DoSomething(MyClass::A); // Current way to access t=
he enum
<br>=C2=A0 =C2=A0 Class.DoSomething(B); =C2=A0// Ambuiguity?
<br>}
<br>
<br>Would this now cause an ambiguity?
<br>
<br>Here a variation of the same theme:
<br>
<br>struct MyClass
<br>{
<br>=C2=A0 =C2=A0 enum MyEnum =C2=A0{ A, B, C, D };
<br>=C2=A0 =C2=A0 void DoSomething(const MyEnum Enum)
<br>=C2=A0 =C2=A0 {
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 //
<br>=C2=A0 =C2=A0 }
<br>};
<br>
<br>struct Other
<br>{
<br>=C2=A0 operator MyClass::MyEnum() const;
<br>} B;
<br>
<br>void Function(MyClass& Class)
<br>{
<br>=C2=A0 =C2=A0 Class.DoSomething(MyClass::A); // Current way to access t=
he enum
<br>=C2=A0 =C2=A0 Class.DoSomething(B); // Ambuiguity?
<br>}
<br>
<br>> See, the compiler knows that an enum of type MyClass::MyEnum is ex=
pected, to
<br>> why would i need to write MyClass:: everywhere? The compiler can i=
mplicitly
<br>> lookup within this namespace first without abiguity.
<br>
<br>See the examples above where (without any extra-rules involved) an
<br>ambiguity would occur or I would not know how to realize the original
<br>(current) meaning.
<br>
<br>> It is most likely that A,B.. and so on are descriptive enough that=
the whole
<br>> Function call makes a valid reading without the MyClass::.
<br>>
<br>> Such language functionality would need clarification what happens =
if there
<br>> is a variable called exactly like an enum member - i guess this sh=
ould throw
<br>> a warning and may be decided on lvalue vs rvalue usage.
<br>
<br>The warning does not solve the programming problem.
<br>
<br>> MyClass:MyEnum A =3D A; // variable A is asigned MyClass:MyEnum::A=
- please
<br>> throw a warning. =C2=A0(That A is the symbol here can be deduced f=
rom context
<br>> again)
<br>> Class.DoSomething(A) // in this case the variable should be used, =
not the
<br>> Symbol.
<br>>
<br>> Another problematic situation is:
<br>>
<br>> void Function(MyClass& Class)
<br>> {
<br>> =C2=A0 =C2=A0 enum MyEnum =C2=A0{ A, B, C, D };
<br>> =C2=A0 =C2=A0 Class.DoSomething(MyClass::A); // Current way to acc=
ess the enum
<br>> =C2=A0 =C2=A0 Class.DoSomething(B); // Which B is used? The right =
one of course - the
<br>> B that machtes the type thats requested.
<br>> =C2=A0 =C2=A0 Class.DoSomething(MyClass::<wbr>MyEnum(::B)); // if =
you want to use the other
<br>> B, use :: to escape from the inplicit namespace lookup
<br>>
<br>> }
<br>>
<br>>
<br>> I hope this is worth a thought. This would diminish the need for l=
onger than
<br>> necessary enum symbols and may even make for an easier read most o=
f the
<br>> time.
<br>
<br>IMO it is not worth it unless you give a way to the programmer to
<br>resolve the ambiguity to either the one or the other direction. In
<br>particular your suggestion would silently change the meaning of
<br>existing programs without making them ill-formed which is one of the
<br>worst kind of problems.
<br>
<br>I would be more sympathetic with your proposal if it would would
<br>suggest to provide a kind of using declaration such as the following:
<br>
<br>struct MyClass
<br>{
<br>=C2=A0 =C2=A0 enum MyEnum =C2=A0{ A, B, C, D };
<br>=C2=A0 =C2=A0 void DoSomething(const MyEnum Enum)
<br>=C2=A0 =C2=A0 {
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 //
<br>=C2=A0 =C2=A0 }
<br>};
<br>
<br>void Function(MyClass& Class)
<br>{
<br>=C2=A0 =C2=A0 Class.DoSomething(MyClass::A); // Current way to access t=
he enum
<br>=C2=A0 =C2=A0 using MyClass::B;
<br>=C2=A0 =C2=A0 // using MyClass::MyEnum to provide access to all enumera=
tors.
<br>=C2=A0 =C2=A0 Class.DoSomething(B); // New way to access the enum?
<br>}
<br></blockquote><div><br>But that makes the proposal rather pointless. The=
whole idea is to make the short and obvious code do the obvious thing. If =
you have to have every function where you're calling these things quali=
fied with a `using` declaration, then you're just making the code longe=
r in a different way.<br><br>Now, I don't agree with the proposal. But =
your suggestion doesn't really achieve the goal that the proposal is tr=
ying to achieve.<br><br>Not only that, you can't exactly stick a `using=
` directive in a=20
default member initializer or a member initialization list. Or in=20
various other places. Also, `using` directives have a tendency to leak,=20
so you can't just stick them in a file header somewhere. So it lack the=
universal nature of the original.<br><br>If the problem is deciding betwee=
n whether an identifier is meant to be a variable name or an enumerator nam=
e, then perhaps that's something we could resolve. We simply need to ap=
ply some qualification to the name to tell the compiler that this is an enu=
merator and we want to resolve the actual enumerator it based on the contex=
t. We could employ a symbol or a keyword to do so. `.enumerator` or `enum e=
numerator`, perhaps. The latter is a bit long, but it's generally longe=
r than most namespaces and/or class names.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/657ec96a-10f7-4b31-bf22-3961b81cddc2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/657ec96a-10f7-4b31-bf22-3961b81cddc2=
%40isocpp.org</a>.<br />
------=_Part_2134_587964710.1495388499328--
------=_Part_2133_591984265.1495388499328--
.
Author: Larry Evans <cppljevans@suddenlink.net>
Date: Sun, 21 May 2017 18:33:40 -0500
Raw View
On 05/21/2017 12:41 PM, Nicol Bolas wrote:
> On Sunday, May 21, 2017 at 12:55:08 PM UTC-4, Daniel Kr=C3=BCgler wrote:
>=20
> 2017-05-21 15:23 GMT+02:00 DerAlbi <thea...@gmail.com>:
> > Hi guys,
> >
> > enums are a handy way to describe typesafe magic values in C++ or
> to define
> > descriptive parameters.
> > However they sit within the namespace they are declared in which
> may become
> > too crowded way too fast.
>=20
> One should be cautious with such an assertion, since these scopes are
> valuable as well, since they reduce the risk of ambiguities.
>=20
> > One solution is to declare enums within a class or namespace - so
> you have
> > class specific enums which makes sence if a class is handling a
> specific
> > subset of functionality so you only may need the enums there anywa=
y.
> >
> > So...
> >
> > struct MyClass
> > {
> > enum MyEnum { A, B, C, D };
> > void DoSomething(const MyEnum Enum)
> > {
> > //
> > }
> > };
> >
> > void Function(MyClass& Class)
> > {
> > Class.DoSomething(MyClass::A); // Current way to access the en=
um
> > Class.DoSomething(B); // New way to access the enum?
> > }
>=20
> Consider a slight variant of this:
>=20
> struct MyClass
> {
> enum MyEnum { A, B, C, D };
> void DoSomething(const MyEnum Enum)
> {
> //
> }
> };
>=20
> MyClass::MyEnum B =3D MyClass::MyEnum::B;
>=20
> void Function(MyClass& Class)
> {
> Class.DoSomething(MyClass::A); // Current way to access the enum
> Class.DoSomething(B); // Ambuiguity?
> }
>=20
> Would this now cause an ambiguity?
>=20
> Here a variation of the same theme:
>=20
> struct MyClass
> {
> enum MyEnum { A, B, C, D };
> void DoSomething(const MyEnum Enum)
> {
> //
> }
> };
>=20
> struct Other
> {
> operator MyClass::MyEnum() const;
> } B;
>=20
> void Function(MyClass& Class)
> {
> Class.DoSomething(MyClass::A); // Current way to access the enum
> Class.DoSomething(B); // Ambuiguity?
> }
>=20
> > See, the compiler knows that an enum of type MyClass::MyEnum is
> expected, to
> > why would i need to write MyClass:: everywhere? The compiler can
> implicitly
> > lookup within this namespace first without abiguity.
>=20
> See the examples above where (without any extra-rules involved) an
> ambiguity would occur or I would not know how to realize the original
> (current) meaning.
>=20
> > It is most likely that A,B.. and so on are descriptive enough
> that the whole
> > Function call makes a valid reading without the MyClass::.
> >
> > Such language functionality would need clarification what happens
> if there
> > is a variable called exactly like an enum member - i guess this
> should throw
> > a warning and may be decided on lvalue vs rvalue usage.
>=20
> The warning does not solve the programming problem.
>=20
> > MyClass:MyEnum A =3D A; // variable A is asigned MyClass:MyEnum::A
> - please
> > throw a warning. (That A is the symbol here can be deduced from
> context
> > again)
> > Class.DoSomething(A) // in this case the variable should be used,
> not the
> > Symbol.
> >
> > Another problematic situation is:
> >
> > void Function(MyClass& Class)
> > {
> > enum MyEnum { A, B, C, D };
> > Class.DoSomething(MyClass::A); // Current way to access the en=
um
> > Class.DoSomething(B); // Which B is used? The right one of
> course - the
> > B that machtes the type thats requested.
> > Class.DoSomething(MyClass::MyEnum(::B)); // if you want to
> use the other
> > B, use :: to escape from the inplicit namespace lookup
> >
> > }
> >
> >
> > I hope this is worth a thought. This would diminish the need for
> longer than
> > necessary enum symbols and may even make for an easier read most
> of the
> > time.
>=20
> IMO it is not worth it unless you give a way to the programmer to
> resolve the ambiguity to either the one or the other direction. In
> particular your suggestion would silently change the meaning of
> existing programs without making them ill-formed which is one of the
> worst kind of problems.
>=20
> I would be more sympathetic with your proposal if it would would
> suggest to provide a kind of using declaration such as the following:
>=20
> struct MyClass
> {
> enum MyEnum { A, B, C, D };
> void DoSomething(const MyEnum Enum)
> {
> //
> }
> };
>=20
> void Function(MyClass& Class)
> {
> Class.DoSomething(MyClass::A); // Current way to access the enum
> using MyClass::B;
> // using MyClass::MyEnum to provide access to all enumerators.
> Class.DoSomething(B); // New way to access the enum?
> }
>=20
>=20
> But that makes the proposal rather pointless. The whole idea is to make=
=20
> the short and obvious code do the obvious thing. If you have to have=20
> every function where you're calling these things qualified with a=20
> `using` declaration, then you're just making the code longer in a=20
> different way.
>=20
> Now, I don't agree with the proposal. But your suggestion doesn't really=
=20
> achieve the goal that the proposal is trying to achieve.
>=20
> Not only that, you can't exactly stick a `using` directive in a default=
=20
> member initializer or a member initialization list. Or in various other=
=20
> places. Also, `using` directives have a tendency to leak, so you can't=20
> just stick them in a file header somewhere. So it lack the universal=20
> nature of the original.
Just to clarify:
using MyClass::B;
is a using declaration, and:
// using MyClass::MyEnum
is, if uncommented, a *proposed* using directive?
BTW, to make syntax more consistent with existing using directives,
I'd suggest:
using enum MyClass::MyEnum;//brings MyClass::MyEnum::A..D in scope
Is that right?
[snip]
--=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/oft81u%24pi7%241%40blaine.gmane.org.
.
Author: thealbig@gmail.com
Date: Sun, 21 May 2017 16:39:52 -0700 (PDT)
Raw View
------=_Part_879_577697285.1495409992518
Content-Type: multipart/alternative;
boundary="----=_Part_880_105518270.1495409992519"
------=_Part_880_105518270.1495409992519
Content-Type: text/plain; charset="UTF-8"
I agree that the ambiguity between variable name and enum member is a big
problem and that my suggestion above would break existing code.
The way to go in that case would be to give the local variable dominance
the same way a local variable shadows a global variable and so on. As with
the shadowing this still can trigger a warning in the same way variable
shadowing does.
So basically i would change my suggestion in that way that the namespace
where the expected enum is declared in is added to the look up
automatically - may it be with the lowest priority... this would not break
existing code but still solves the issue of lowering code complexity for
the future.
MyClass::MyEnum A = A; would then trigger a self assignment warning; or use
of unitialized variable or whatever, which is ok too. I mean... people with
those naming schemes deserve it.
The point is in most cases this will greatly reduce code complexity, keep
the namespaces cleaner and makes the code easier to read. Additionally you
can declare stuff where you actually use it without the penalty of
excessive code typing.
I really would like to solve the issue at the look-up level. Adding
additional key words or reuse something like __decltype(auto)::A to
indicate that the compiler shall look up the expected class at this
location is just adding inconvinience again. The point is to keep the code
short, readable and the cost of clean namespaces low.
--
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/e07e5dd2-073d-4f16-9ed7-46f93d8f2761%40isocpp.org.
------=_Part_880_105518270.1495409992519
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I agree that the ambiguity between variable name and enum =
member is a big problem and that my suggestion above would break existing c=
ode. <br>The way to go in that case would be to give the local variable dom=
inance the same way a local variable shadows a global variable and so on. A=
s with the shadowing this still can trigger a warning in the same way varia=
ble shadowing does. <br><br>So basically i would change my suggestion in th=
at way that the namespace where the expected enum is declared in is added t=
o the look up automatically - may it be with the lowest priority... this wo=
uld not break existing code but still solves the issue of lowering code com=
plexity for the future.<br><br>MyClass::MyEnum A =3D A; would then trigger =
a self assignment warning; or use of unitialized variable or whatever, whic=
h is ok too. I mean... people with those naming schemes deserve it.<br>The =
point is in most cases this will greatly reduce code complexity, keep the n=
amespaces cleaner and makes the code easier to read. Additionally you can d=
eclare stuff where you actually use it without the penalty of excessive cod=
e typing.<br>I really would like to solve the issue at the look-up level. A=
dding additional key words or reuse something like __decltype(auto)::A to i=
ndicate that the compiler shall look up the expected class at this location=
is just adding inconvinience again. The point is to keep the code short, r=
eadable and the cost of clean namespaces low.<br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/e07e5dd2-073d-4f16-9ed7-46f93d8f2761%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e07e5dd2-073d-4f16-9ed7-46f93d8f2761=
%40isocpp.org</a>.<br />
------=_Part_880_105518270.1495409992519--
------=_Part_879_577697285.1495409992518--
.
Author: thealbig@gmail.com
Date: Sun, 21 May 2017 16:50:23 -0700 (PDT)
Raw View
------=_Part_2311_1096131000.1495410623659
Content-Type: multipart/alternative;
boundary="----=_Part_2312_1338019941.1495410623659"
------=_Part_2312_1338019941.1495410623659
Content-Type: text/plain; charset="UTF-8"
Larry we wrote our answer at the same time. Bringing the namespace
explicitly into the scope is not my point. Of course this is a workaround,
however for a one time use of an enum (due to a single parameter in a
function call or whatever) you would need to add this line of code which is
even more text than i try to get rid of. The compiler does allready have
the knowledge which type is expected and which namespace is therefore
likely to be meant. If the enum member is not shadowed, it should just
assume the right namespace.
As i wrote in my previous post, i dont have an issue if such look up would
occur after every other lookup is unsuccessfull.
--
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/6aac70ca-d374-4858-ad1c-cecc882330b3%40isocpp.org.
------=_Part_2312_1338019941.1495410623659
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Larry we wrote our answer at the same time. Bringing the n=
amespace explicitly into the scope is not my point. Of course this is a wor=
karound, however for a one time use of an enum (due to a single parameter i=
n a function call or whatever) you would need to add this line of code whic=
h is even more text than i try to get rid of. The compiler does allready ha=
ve the knowledge which type is expected and which namespace is therefore li=
kely to be meant. If the enum member is not shadowed, it should just assume=
the right namespace. <br>As i wrote in my previous post, i dont have an is=
sue if such look up would occur after every other lookup is unsuccessfull.<=
br><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/6aac70ca-d374-4858-ad1c-cecc882330b3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6aac70ca-d374-4858-ad1c-cecc882330b3=
%40isocpp.org</a>.<br />
------=_Part_2312_1338019941.1495410623659--
------=_Part_2311_1096131000.1495410623659--
.
Author: =?UTF-8?Q?Daniel_Kr=C3=BCgler?= <daniel.kruegler@gmail.com>
Date: Mon, 22 May 2017 07:01:48 +0200
Raw View
2017-05-22 1:33 GMT+02:00 Larry Evans <cppljevans@suddenlink.net>:
> Just to clarify:
>
> using MyClass::B;
>
> is a using declaration, and:
>
> // using MyClass::MyEnum
>
> is, if uncommented, a *proposed* using directive?
Yes (I apologize for the misleading term usage).
> BTW, to make syntax more consistent with existing using directives,
> I'd suggest:
>
> using enum MyClass::MyEnum;//brings MyClass::MyEnum::A..D in scope
>
> Is that right?
For scoped enumeration types, I agree. I'm open in regard to unscoped
enumeration types (which have been used in the OP's example).
- Daniel
--
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/CAGNvRgC0nTxCFVAqZF0aEEJ8F8wWWDSZNoSLUKvUx2n6bNYssQ%40mail.gmail.com.
.
Author: thealbig@gmail.com
Date: Mon, 22 May 2017 02:56:50 -0700 (PDT)
Raw View
------=_Part_187_884944863.1495447010935
Content-Type: multipart/alternative;
boundary="----=_Part_188_205887748.1495447010936"
------=_Part_188_205887748.1495447010936
Content-Type: text/plain; charset="UTF-8"
I am not sure how to handle "enum" vs "enum class" here too.
It really depends on what the stronger intent of the enum class was - for
me the stronger aspect is that implicit conversions arent possible. The
explicit mentioning of the type to access the member however... i dont
know.. it can be part of a good readable naming scheme however my proposal
wouldnt stand in the way to still mention the type i guess.. after all it
shall not break code.
I feel like the enum class is even more made for this automatic scope
lookup... while a normal enum might be shadowed, with an enum class there
is no doubt which namespace is the only correct one because without
implicit conversion nothing else makes sense in context of e.g. a function
argument.
So spare the typing.
i could also agree with a proposal to changing the language more than just
on the look-up side of things...
Requireing something like void MyClass::PassMeAnEnum(*using *MyClass::MyEnum
Enum) during declaration to indicate default enum-namespace lookup at this
point would be acceptable.
However i guess once the feature would be in the language the "using" term
is will sound like a mockery since you have to put it everywhere anyways...
so well... i would agree but i wouldnt like it very much.
By the way: just an example from last night: (i come from the embedded
side; have an extern DAC to adjust the voltage somewhere..)
ExtDac.SetChannel(2, CDAC084::eDACAction::WriteAndUpdate, Voltage);
Would it be really worse if it were just: ExtDac.SetChannel(2,
WriteAndUpdate, Voltage);
...i can have that now, but it would force me to declare the enum out of
context. Sucks.
btw i really stuggle with this google stuff :-/ strange.
--
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/073aeda7-9360-4462-8cbc-663b65f13bf2%40isocpp.org.
------=_Part_188_205887748.1495447010936
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I am not sure how to handle "enum" vs "enum=
class" here too.<br>It really depends on what the stronger intent of =
the enum class was - for me the stronger aspect is that implicit conversion=
s arent possible. The explicit mentioning of the type to access the member =
however... i dont know.. it can be part of a good readable naming scheme ho=
wever my proposal wouldnt stand in the way to still mention the type i gues=
s.. after all it shall not break code.<br>I feel like the enum class is eve=
n more made for this automatic scope lookup...=C2=A0 while a normal enum mi=
ght be shadowed, with an enum class there is no doubt which namespace is th=
e only correct one because without implicit conversion nothing else makes s=
ense in context of e.g. a function argument. <br>So spare the typing.<br><b=
r>i could also agree with a proposal to changing the language more than jus=
t on the look-up side of things...<br>Requireing something like void MyClas=
s::PassMeAnEnum(<b>using </b>MyClass::MyEnum Enum)=C2=A0 during declaration=
to indicate default enum-namespace lookup at this point would be acceptabl=
e.<br>However i guess once the feature would be in the language the "u=
sing" term is will sound like a mockery since you have to put it every=
where anyways... so well...=C2=A0 i would agree but i wouldnt like it very =
much.<br><br>By the way: just an example from last night: (i come from the =
embedded side; have an extern DAC to adjust the voltage somewhere..)<br>Ext=
Dac.SetChannel(2, CDAC084::eDACAction::WriteAndUpdate, Voltage);<br><br>Wou=
ld it be really worse if it were just: ExtDac.SetChannel(2, WriteAndUpdate,=
Voltage);<br>..i can have that now, but it would force me to declare the e=
num out of context. Sucks.<br><br>btw i really stuggle with this google stu=
ff :-/ strange.<br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/073aeda7-9360-4462-8cbc-663b65f13bf2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/073aeda7-9360-4462-8cbc-663b65f13bf2=
%40isocpp.org</a>.<br />
------=_Part_188_205887748.1495447010936--
------=_Part_187_884944863.1495447010935--
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Mon, 22 May 2017 15:42:43 -0700 (PDT)
Raw View
------=_Part_1336_1241921730.1495492963176
Content-Type: multipart/alternative;
boundary="----=_Part_1337_408466032.1495492963176"
------=_Part_1337_408466032.1495492963176
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
I don't think that proposals suggesting that the type of an expression=20
should depend on what it is used for will go very far. This idea clashes=20
with function overloading and is not employed currently except when sending=
=20
a function pointer to a (non-overloaded) function.
However, bringing all enumerators into scope with a using declaration would=
=20
be a good feature useful for instance when implementing a state machine=20
that juggles those identifiers extensively in a function. Also when you=20
make a switch over an enum you still have to scope all the case labels=20
which is very ugly.
Maybe this feature has to have a special syntax such as using MyEnum::*; to=
=20
avoid backward compatiblibity issues. If so it is somewhat awkward but=20
still better than the current situation, I think.
Den m=C3=A5ndag 22 maj 2017 kl. 11:56:51 UTC+2 skrev thea...@gmail.com:
>
> I am not sure how to handle "enum" vs "enum class" here too.
> It really depends on what the stronger intent of the enum class was - for=
=20
> me the stronger aspect is that implicit conversions arent possible. The=
=20
> explicit mentioning of the type to access the member however... i dont=20
> know.. it can be part of a good readable naming scheme however my proposa=
l=20
> wouldnt stand in the way to still mention the type i guess.. after all it=
=20
> shall not break code.
> I feel like the enum class is even more made for this automatic scope=20
> lookup... while a normal enum might be shadowed, with an enum class ther=
e=20
> is no doubt which namespace is the only correct one because without=20
> implicit conversion nothing else makes sense in context of e.g. a functio=
n=20
> argument.=20
> So spare the typing.
>
> i could also agree with a proposal to changing the language more than jus=
t=20
> on the look-up side of things...
> Requireing something like void MyClass::PassMeAnEnum(*using *MyClass::MyE=
num=20
> Enum) during declaration to indicate default enum-namespace lookup at th=
is=20
> point would be acceptable.
> However i guess once the feature would be in the language the "using" ter=
m=20
> is will sound like a mockery since you have to put it everywhere anyways.=
...=20
> so well... i would agree but i wouldnt like it very much.
>
> By the way: just an example from last night: (i come from the embedded=20
> side; have an extern DAC to adjust the voltage somewhere..)
> ExtDac.SetChannel(2, CDAC084::eDACAction::WriteAndUpdate, Voltage);
>
> Would it be really worse if it were just: ExtDac.SetChannel(2,=20
> WriteAndUpdate, Voltage);
> ..i can have that now, but it would force me to declare the enum out of=
=20
> context. Sucks.
>
> btw i really stuggle with this google stuff :-/ strange.
>
--=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/e4a77a62-5e87-4b9b-b910-94e2472c27ba%40isocpp.or=
g.
------=_Part_1337_408466032.1495492963176
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I don't think that proposals suggesting that the type =
of an expression should depend on what it is used for will go very far. Thi=
s idea clashes with function overloading and is not employed currently exce=
pt when sending a function pointer to a (non-overloaded) function.<div><br>=
</div><div>However, bringing all enumerators into scope with a using declar=
ation would be a good feature useful for instance when implementing a state=
machine that juggles those identifiers extensively in a function. Also whe=
n you make a switch over an enum you still have to scope all the case label=
s which is very ugly.</div><div><br></div><div>Maybe this feature has to ha=
ve a special syntax such as using MyEnum::*; to avoid backward compatiblibi=
ty issues. If so it is somewhat awkward but still better than the current s=
ituation, I think.</div><div><br></div><div><br>Den m=C3=A5ndag 22 maj 2017=
kl. 11:56:51 UTC+2 skrev thea...@gmail.com:<blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"ltr">I am not sure how to handle "enum"=
vs "enum class" here too.<br>It really depends on what the stron=
ger intent of the enum class was - for me the stronger aspect is that impli=
cit conversions arent possible. The explicit mentioning of the type to acce=
ss the member however... i dont know.. it can be part of a good readable na=
ming scheme however my proposal wouldnt stand in the way to still mention t=
he type i guess.. after all it shall not break code.<br>I feel like the enu=
m class is even more made for this automatic scope lookup...=C2=A0 while a =
normal enum might be shadowed, with an enum class there is no doubt which n=
amespace is the only correct one because without implicit conversion nothin=
g else makes sense in context of e.g. a function argument. <br>So spare the=
typing.<br><br>i could also agree with a proposal to changing the language=
more than just on the look-up side of things...<br>Requireing something li=
ke void MyClass::PassMeAnEnum(<b>using </b>MyClass::MyEnum Enum)=C2=A0 duri=
ng declaration to indicate default enum-namespace lookup at this point woul=
d be acceptable.<br>However i guess once the feature would be in the langua=
ge the "using" term is will sound like a mockery since you have t=
o put it everywhere anyways... so well...=C2=A0 i would agree but i wouldnt=
like it very much.<br><br>By the way: just an example from last night: (i =
come from the embedded side; have an extern DAC to adjust the voltage somew=
here..)<br>ExtDac.SetChannel(2, CDAC084::eDACAction::<wbr>WriteAndUpdate, V=
oltage);<br><br>Would it be really worse if it were just: ExtDac.SetChannel=
(2, WriteAndUpdate, Voltage);<br>..i can have that now, but it would force =
me to declare the enum out of context. Sucks.<br><br>btw i really stuggle w=
ith this google stuff :-/ strange.<br></div></blockquote></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/e4a77a62-5e87-4b9b-b910-94e2472c27ba%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e4a77a62-5e87-4b9b-b910-94e2472c27ba=
%40isocpp.org</a>.<br />
------=_Part_1337_408466032.1495492963176--
------=_Part_1336_1241921730.1495492963176--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 22 May 2017 16:30:30 -0700 (PDT)
Raw View
------=_Part_3187_299930360.1495495830869
Content-Type: multipart/alternative;
boundary="----=_Part_3188_962187478.1495495830869"
------=_Part_3188_962187478.1495495830869
Content-Type: text/plain; charset="UTF-8"
On Monday, May 22, 2017 at 6:42:43 PM UTC-4, Bengt Gustafsson wrote:
>
> I don't think that proposals suggesting that the type of an expression
> should depend on what it is used for will go very far. This idea clashes
> with function overloading and is not employed currently except when sending
> a function pointer to a (non-overloaded) function.
>
It's no different from what list initialization does. If you make it a
braced-init-list-like "not an expression" construct, then it could be
perfectly functional.
--
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/ed3dd06f-15a2-4f54-9003-598df5b3558d%40isocpp.org.
------=_Part_3188_962187478.1495495830869
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, May 22, 2017 at 6:42:43 PM UTC-4, Bengt Gustafs=
son wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">I d=
on't think that proposals suggesting that the type of an expression sho=
uld depend on what it is used for will go very far. This idea clashes with =
function overloading and is not employed currently except when sending a fu=
nction pointer to a (non-overloaded) function.</div></blockquote><div><br>I=
t's no different from what list initialization does. If you make it a b=
raced-init-list-like "not an expression" construct, then it could=
be perfectly functional.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/ed3dd06f-15a2-4f54-9003-598df5b3558d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ed3dd06f-15a2-4f54-9003-598df5b3558d=
%40isocpp.org</a>.<br />
------=_Part_3188_962187478.1495495830869--
------=_Part_3187_299930360.1495495830869--
.
Author: Larry Evans <cppljevans@suddenlink.net>
Date: Mon, 22 May 2017 18:34:02 -0500
Raw View
On 05/22/2017 05:42 PM, Bengt Gustafsson wrote:
[snip]
> Maybe this feature has to have a special syntax such as using MyEnum::*;
> to avoid backward compatiblibity issues. If so it is somewhat awkward
> but still better than the current situation, I think.
To be consistent, then, the using directive:
using namespace MyNamespace;
should have been:
using MyNamespace::*;
it seems to me.
[snip]
--
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/ofvsh6%24n4q%241%40blaine.gmane.org.
.
Author: thealbig@gmail.com
Date: Mon, 22 May 2017 19:01:35 -0700 (PDT)
Raw View
------=_Part_3182_147457346.1495504895548
Content-Type: multipart/alternative;
boundary="----=_Part_3183_1993739297.1495504895548"
------=_Part_3183_1993739297.1495504895548
Content-Type: text/plain; charset="UTF-8"
No, i am not sold on the using-stuff. Since i have embedded hardware
background i apologize if i use real world situations which some might not
find intuitive, but just consider:
Pin.Level = High; //spare me
CPinClass<templatestuff?>::CAsOutput::ePinLevel::
Pin.Speed = High; //spare me
CPinClass<templatestuff?>::CAsOutput::ePinSpeed::
This is perfectly readable code, yet the High for the Pin-level is just a 1
while the High for the Speed is maybe a 3 because a Pin might support 4
different toggle speeds.
I am not sure why you would need to write ever more than that. Enums exist
to be _descriptive_ magic values, so if a enum (class) is expected, just go
in the right namespace to look for it after all other possibilities are
explored unsuccessfully.
I also dont understand the problem with overloading:
int a(MyEnum Enum);
int a(int Integer)
calling a(5) and a(EnumMember) is perfectly distinguishable even if
MyEnum is just an enum and not an enum class, because afaik the one without
the implicit conversion is chosen.
A problem arises, if there is something like
int a(MyEnum_1 Enum_1);
int a(MyEnum_2 Enum_2);
If MyEnum_1 and MyEnum_2 share equally named members, than.. well.. you can
still call the right function by using the full name of the enum and
without that just throw an ambiguity error - its not that this is a
uncommon thing or a case that should cause headace.
This wouldnt even break existing code. Existing code does not compile if
symbols arent found before the enum namespace is considered implicitly.
Can anyone make a concrete example where my proposal causes a problem, if
the name look up for the enum member is done in the corresponding enum
namespace last? And i am just talking about enums (their member names),
nothing else.
What exactly is the point of invoking the enum namespace explicitly? How
will overlapping enum member names be managed with 'using' if you use 2
different enums with equal member names? I think being context aware
solves this easily.
Can this context awareness for enums be a problem? How ? :-O
--
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/dab20fd4-af9c-4942-881f-f9ca5ab0de7f%40isocpp.org.
------=_Part_3183_1993739297.1495504895548
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">No, i am not sold on the using-stuff. Since i have embedde=
d hardware background i apologize if i use real world situations which some=
might not find intuitive, but just consider:<br><br>Pin.Level =3D High;=C2=
=A0=C2=A0 //spare me CPinClass<templatestuff?>::CAsOutput::ePinLevel:=
:<br>Pin.Speed =3D High; //spare me CPinClass<templatestuff?>::CAsOut=
put::ePinSpeed::<br><br>This is perfectly readable code, yet the High for t=
he Pin-level is just a 1 while the High for the Speed is maybe a 3 because =
a Pin might support 4 different toggle speeds.<br>I am not sure why you wou=
ld need to write ever more than that. Enums exist to be _descriptive_ magic=
values, so if a enum (class) is expected, just go in the right namespace t=
o look for it after all other possibilities are explored unsuccessfully.<br=
><br>I also dont understand the problem with overloading:<br><br>int a(MyEn=
um Enum);<br>int a(int Integer)<br><br>calling a(5)=C2=A0 and a(EnumMember)=
=C2=A0 is perfectly distinguishable even if MyEnum is just an enum and not =
an enum class, because afaik the one without the implicit conversion is cho=
sen.<br><br>A problem arises, if there is something like<br>int a(MyEnum_1=
=C2=A0 Enum_1);<br>int a(MyEnum_2=C2=A0 Enum_2);<br><br>If MyEnum_1 and MyE=
num_2 share equally named members, than.. well.. you can still call the rig=
ht function by using the full name of the enum and without that just throw =
an ambiguity error - its not that this is a uncommon thing or a case that s=
hould cause headace.<br>This wouldnt even break existing code. Existing cod=
e does not compile if symbols arent found before the enum namespace is cons=
idered implicitly.<br><br>Can anyone make a concrete example where my propo=
sal causes a problem, if the name look up for the enum member is done in th=
e corresponding enum namespace last? And i am just talking about enums (the=
ir member names), nothing else.<br>What exactly is the point of invoking th=
e enum namespace explicitly? How will overlapping enum member names be mana=
ged with 'using' if you use 2 different enums with equal member nam=
es?=C2=A0 I think being context aware solves this easily. <br>Can this cont=
ext awareness for enums be a problem? How ? :-O<br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/dab20fd4-af9c-4942-881f-f9ca5ab0de7f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/dab20fd4-af9c-4942-881f-f9ca5ab0de7f=
%40isocpp.org</a>.<br />
------=_Part_3183_1993739297.1495504895548--
------=_Part_3182_147457346.1495504895548--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 23 May 2017 07:21:30 -0700 (PDT)
Raw View
------=_Part_3586_1612064310.1495549290563
Content-Type: multipart/alternative;
boundary="----=_Part_3587_321948282.1495549290563"
------=_Part_3587_321948282.1495549290563
Content-Type: text/plain; charset="UTF-8"
On Monday, May 22, 2017 at 10:01:35 PM UTC-4, thea...@gmail.com wrote:
>
> No, i am not sold on the using-stuff. Since i have embedded hardware
> background i apologize if i use real world situations which some might not
> find intuitive, but just consider:
>
> Pin.Level = High; //spare me
> CPinClass<templatestuff?>::CAsOutput::ePinLevel::
> Pin.Speed = High; //spare me
> CPinClass<templatestuff?>::CAsOutput::ePinSpeed::
>
> This is perfectly readable code, yet the High for the Pin-level is just a
> 1 while the High for the Speed is maybe a 3 because a Pin might support 4
> different toggle speeds.
> I am not sure why you would need to write ever more than that. Enums exist
> to be _descriptive_ magic values, so if a enum (class) is expected, just go
> in the right namespace to look for it after all other possibilities are
> explored unsuccessfully.
>
> I also dont understand the problem with overloading:
>
> int a(MyEnum Enum);
> int a(int Integer)
>
> calling a(5) and a(EnumMember) is perfectly distinguishable even if
> MyEnum is just an enum and not an enum class, because afaik the one without
> the implicit conversion is chosen.
>
> A problem arises, if there is something like
> int a(MyEnum_1 Enum_1);
> int a(MyEnum_2 Enum_2);
>
> If MyEnum_1 and MyEnum_2 share equally named members, than.. well.. you
> can still call the right function by using the full name of the enum and
> without that just throw an ambiguity error - its not that this is a
> uncommon thing or a case that should cause headace.
> This wouldnt even break existing code. Existing code does not compile if
> symbols arent found before the enum namespace is considered implicitly.
>
> Can anyone make a concrete example where my proposal causes a problem, if
> the name look up for the enum member is done in the corresponding enum
> namespace last? And i am just talking about enums (their member names),
> nothing else.
>
We've already explained where the problem is: if the enumerator has the
same name as an existing variable. Right now, that has a specific meaning.
To do what you want requires either changing that meaning or making your
feature not work in every case.
That's why I suggest using specific syntax to express this, instead of
using just an enumerator name.
> What exactly is the point of invoking the enum namespace explicitly? How
> will overlapping enum member names be managed with 'using' if you use 2
> different enums with equal member names? I think being context aware
> solves this easily.
> Can this context awareness for enums be a problem? How ? :-O
>
C++ only has one other "context aware" system like you're talking about:
list initialization and braced-init-lists. Braced-init-lists perform a type
of initialization on values, and they can deduce what type to initialize
based on where they are used.
That works because the grammar explicitly states that a braced-init-list is *not
an expression*. This allows the standard to define a set of rules that are
distinct from the rules of an expression. This allows the standard to work
around overloading issues and the like.
What you want is for a simple identifier to work the same way. But the
standard doesn't allow that; an identifier is an *expression*, and
therefore must follow the rules of an expression. You cannot make the type
of an expression be context dependent; again, this is why braced-init-lists
aren't expressions.
So yet again, having explicit syntax to invoke this context-specific tool
is vital to making it actually work on a grammatical level. `enum
Enumerator` should be sufficient; it may not be as short as you would like,
but it would actually be a workable solution.
--
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/98a071a6-0d83-4a3b-ac3a-766d11b71366%40isocpp.org.
------=_Part_3587_321948282.1495549290563
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, May 22, 2017 at 10:01:35 PM UTC-4, thea...@gmai=
l.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">N=
o, i am not sold on the using-stuff. Since i have embedded hardware backgro=
und i apologize if i use real world situations which some might not find in=
tuitive, but just consider:<br><br>Pin.Level =3D High;=C2=A0=C2=A0 //spare =
me CPinClass<templatestuff?>::<wbr>CAsOutput::ePinLevel::<br>Pin.Spee=
d =3D High; //spare me CPinClass<templatestuff?>::<wbr>CAsOutput::ePi=
nSpeed::<br><br>This is perfectly readable code, yet the High for the Pin-l=
evel is just a 1 while the High for the Speed is maybe a 3 because a Pin mi=
ght support 4 different toggle speeds.<br>I am not sure why you would need =
to write ever more than that. Enums exist to be _descriptive_ magic values,=
so if a enum (class) is expected, just go in the right namespace to look f=
or it after all other possibilities are explored unsuccessfully.<br><br>I a=
lso dont understand the problem with overloading:<br><br>int a(MyEnum Enum)=
;<br>int a(int Integer)<br><br>calling a(5)=C2=A0 and a(EnumMember)=C2=A0 i=
s perfectly distinguishable even if MyEnum is just an enum and not an enum =
class, because afaik the one without the implicit conversion is chosen.<br>=
<br>A problem arises, if there is something like<br>int a(MyEnum_1=C2=A0 En=
um_1);<br>int a(MyEnum_2=C2=A0 Enum_2);<br><br>If MyEnum_1 and MyEnum_2 sha=
re equally named members, than.. well.. you can still call the right functi=
on by using the full name of the enum and without that just throw an ambigu=
ity error - its not that this is a uncommon thing or a case that should cau=
se headace.<br>This wouldnt even break existing code. Existing code does no=
t compile if symbols arent found before the enum namespace is considered im=
plicitly.<br><br>Can anyone make a concrete example where my proposal cause=
s a problem, if the name look up for the enum member is done in the corresp=
onding enum namespace last? And i am just talking about enums (their member=
names), nothing else.<br></div></blockquote><div><br>We've already exp=
lained where the problem is: if the enumerator has the same name as an exis=
ting variable. Right now, that has a specific meaning. To do what you want =
requires either changing that meaning or making your feature not work in ev=
ery case.<br><br>That's why I suggest using specific syntax to express =
this, instead of using just an enumerator name.<br>=C2=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">What exactly is the point=
of invoking the enum namespace explicitly? How will overlapping enum membe=
r names be managed with 'using' if you use 2 different enums with e=
qual member names?=C2=A0 I think being context aware solves this easily. <b=
r>Can this context awareness for enums be a problem? How ? :-O<br></div></b=
lockquote><div><br>C++ only has one other "context aware" system =
like you're talking about: list initialization and braced-init-lists. B=
raced-init-lists perform a type of initialization on values, and they can d=
educe what type to initialize based on where they are used.<br><br>That wor=
ks because the grammar explicitly states that a braced-init-list is <i>not =
an expression</i>. This allows the standard to define a set of rules that a=
re distinct from the rules of an expression. This allows the standard to wo=
rk around overloading issues and the like.<br><br>What you want is for a si=
mple identifier to work the same way. But the standard doesn't allow th=
at; an identifier is an <i>expression</i>, and therefore must follow the ru=
les of an expression. You cannot make the type of an expression be context =
dependent; again, this is why braced-init-lists aren't expressions.<br>=
<br>So yet again, having explicit syntax to invoke this context-specific to=
ol is vital to making it actually work on a grammatical level. `enum Enumer=
ator` should be sufficient; it may not be as short as you would like, but i=
t would actually be a workable solution.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/98a071a6-0d83-4a3b-ac3a-766d11b71366%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/98a071a6-0d83-4a3b-ac3a-766d11b71366=
%40isocpp.org</a>.<br />
------=_Part_3587_321948282.1495549290563--
------=_Part_3586_1612064310.1495549290563--
.
Author: thealbig@gmail.com
Date: Tue, 23 May 2017 12:19:55 -0700 (PDT)
Raw View
------=_Part_1681_331381552.1495567195117
Content-Type: multipart/alternative;
boundary="----=_Part_1682_1503426462.1495567195117"
------=_Part_1682_1503426462.1495567195117
Content-Type: text/plain; charset="UTF-8"
>
>
> We've already explained where the problem is: if the enumerator has the
> same name as an existing variable. Right now, that has a specific meaning.
> To do what you want requires either changing that meaning or making your
> feature not work in every case.
>
> That's why I suggest using specific syntax to express this, instead of
> using just an enumerator name.
>
Sry Nicol that i am so complicated, can you write up a small snippet to
illustrate this?
I explicitly changed my opinion to invoke this feature only if all other
options fail to compile - meaning the name lookup found no option. Only
then lookup in the expected enum namespace.
In other words, the proposed feature is not enabled in code that would
currently compile successfully because the name lookup found a satisfying
symbol before its desperate enough to search withing the expected enum
namespace.
This solves shadowing pretty easy and will not break currently working code
in my eyes, but i am open to learn. Its very possible that i am too dumb to
understand a lof of the high level concerns, so please fight with me..
maybe I understand code better than the formal language about the code
itself.
--
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/9a570252-4811-480c-8d16-b3d2eac95e36%40isocpp.org.
------=_Part_1682_1503426462.1495567195117
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><br>We've already explained where the problem is: if the enume=
rator has the same name as an existing variable. Right now, that has a spec=
ific meaning. To do what you want requires either changing that meaning or =
making your feature not work in every case.<br><br>That's why I suggest=
using specific syntax to express this, instead of using just an enumerator=
name.</div></div></blockquote><div><br>Sry Nicol that i am so complicated,=
can you write up a small snippet to illustrate this?=C2=A0 <br>I explicitl=
y changed my opinion to invoke this feature only if all other options fail =
to compile - meaning the name lookup found no option. Only then lookup in t=
he expected enum namespace.<br>In other words, the proposed feature is not =
enabled in code that would currently compile successfully because the name =
lookup found a satisfying symbol before its desperate enough to search with=
ing the expected enum namespace.<br>This solves shadowing pretty easy and w=
ill not break currently working code in my eyes, but i am open to learn. It=
s very possible that i am too dumb to understand a lof of the high level co=
ncerns, so please fight with me.. maybe I understand code better than the f=
ormal language about the code itself.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/9a570252-4811-480c-8d16-b3d2eac95e36%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9a570252-4811-480c-8d16-b3d2eac95e36=
%40isocpp.org</a>.<br />
------=_Part_1682_1503426462.1495567195117--
------=_Part_1681_331381552.1495567195117--
.
Author: Larry Evans <cppljevans@suddenlink.net>
Date: Tue, 23 May 2017 15:37:31 -0500
Raw View
This is a multi-part message in MIME format.
--------------F74D700CC24C47EC7D7284B1
Content-Type: text/plain; charset="UTF-8"; format=flowed
On 05/23/2017 02:19 PM, thealbig@gmail.com wrote:
>
> We've already explained where the problem is: if the enumerator has
> the same name as an existing variable. Right now, that has a
> specific meaning. To do what you want requires either changing that
> meaning or making your feature not work in every case.
>
> That's why I suggest using specific syntax to express this, instead
> of using just an enumerator name.
>
>
> Sry Nicol that i am so complicated, can you write up a small snippet to
> illustrate this?
> I explicitly changed my opinion to invoke this feature only if all other
> options fail to compile - meaning the name lookup found no option. Only
> then lookup in the expected enum namespace.
> In other words, the proposed feature is not enabled in code that would
> currently compile successfully because the name lookup found a
> satisfying symbol before its desperate enough to search withing the
> expected enum namespace.
> This solves shadowing pretty easy and will not break currently working
> code in my eyes, but i am open to learn. Its very possible that i am too
> dumb to understand a lof of the high level concerns, so please fight
> with me.. maybe I understand code better than the formal language about
> the code itself.
>
I also have trouble understanding Nicol's viewpoint. So, I created a
small snippet myself which is close to what Nicol had in his earlier
post here:
https://groups.google.com/a/isocpp.org/d/msg/std-proposals/frHziD8lCa4/mckYIw0mAgAJ
The snippet is attached. When defined(USE_VAR) and
!defined(USING_PROPOSED), it compiles and runs with:
implicit_enum_lookup_ambiguity_struct.exe:
implicit_enum_lookup_ambiguity_struct.cpp:13: void
MyClass::DoSomething(const MyClass::MyEnum): Assertion `Enum == A' failed.
OTOH, when defined(USING_PROPOSED), it fails compile with:
implicit_enum_lookup_ambiguity_struct.cpp:26:24: error: using
declaration cannot refer to class member
using MyClass::B;
~~~~~~~~~^
implicit_enum_lookup_ambiguity_struct.cpp:26:9: note: use a constexpr
variable instead
using MyClass::B;
^~~~~
constexpr auto B =
IIUC, what Mr. Krugler was proposing is that:
using MyClass::MyEnum;
would simply be shorthand for:
constexpr auto A=MyClass::A;
constexpr auto B=MyClass::B;
constexpr auto C=MyClass::C;
constexpr auto D=MyClass::D;
What's wrong with simply providing a shorthand for something
already possible?
-regards,
Larry
--
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/og26i7%24am0%241%40blaine.gmane.org.
--------------F74D700CC24C47EC7D7284B1
Content-Type: text/x-c++src;
name="implicit_enum_lookup_ambiguity_struct.cpp"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="implicit_enum_lookup_ambiguity_struct.cpp"
//Purpose:
// By compiling, demonstrate ambiguity in code from:
/*
https://groups.google.com/a/isocpp.org/d/msg/std-proposals/frHziD8lCa4/mckYIw0mAgAJ
*/
//===============================
#include <cassert>
struct MyClass
{
enum MyEnum { A, B, C, D };
void DoSomething(const MyEnum Enum)
{
assert(Enum == A);
}
};
#define USE_VAR
#ifdef USE_VAR
MyClass::MyEnum B = MyClass::MyEnum::A;
#endif
void Function(MyClass& myClass)
{
myClass.DoSomething(MyClass::A); // Current way to access the enum
#define USING_PROPOSED
#ifdef USING_PROPOSED
using MyClass::B;
#else
constexpr auto B=MyClass::B;
#endif
// using MyClass::MyEnum to provide access to all enumerators.
myClass.DoSomething(B); // New way to access the enum?
}
int main()
{
MyClass myClass;
Function(myClass);
return 0;
}
//Result:
/*
-*- mode: compilation; default-directory: "~/prog_dev/c++/standard/proposals/" -*-
Compilation started at Tue May 23 15:09:50
make -k run
/home/evansl/dwnlds/llvm/3.9/prebuilt/clang+llvm-3.9.0-x86_64-linux-gnu-ubuntu-16.04/bin/clang++ -c -O0 -stdlib=libc++ -std=c++1z -ftemplate-backtrace-limit=0 -fdiagnostics-show-template-tree -fno-elide-type -fmacro-backtrace-limit=0 -ftemplate-depth=200 implicit_enum_lookup_ambiguity_struct.cpp -MMD -o /tmp/build/clangxx3_9_pkg/c++/standard/proposals/implicit_enum_lookup_ambiguity_struct.o
implicit_enum_lookup_ambiguity_struct.cpp:26:24: error: using declaration cannot refer to class member
using MyClass::B;
~~~~~~~~~^
implicit_enum_lookup_ambiguity_struct.cpp:26:9: note: use a constexpr variable instead
using MyClass::B;
^~~~~
constexpr auto B =
1 error generated.
/home/evansl/prog_dev/root.imk:172: recipe for target '/tmp/build/clangxx3_9_pkg/c++/standard/proposals/implicit_enum_lookup_ambiguity_struct.o' failed
make: *** [/tmp/build/clangxx3_9_pkg/c++/standard/proposals/implicit_enum_lookup_ambiguity_struct.o] Error 1
make: Target 'run' not remade because of errors.
Compilation exited abnormally with code 2 at Tue May 23 15:09:50
*/
--------------F74D700CC24C47EC7D7284B1--
.
Author: Larry Evans <cppljevans@suddenlink.net>
Date: Tue, 23 May 2017 16:25:42 -0500
Raw View
This is a multi-part message in MIME format.
--------------5015A74B61A1FE6DC4299558
Content-Type: text/plain; charset="UTF-8"; format=flowed
On 05/23/2017 03:37 PM, Larry Evans wrote:
[snip]
> I also have trouble understanding Nicol's viewpoint. So, I created a
> small snippet myself which is close to what Nicol had in his earlier
> post here:
>
> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/frHziD8lCa4/mckYIw0mAgAJ
>
OOPS. That should have been:
small snippet myself which is close to what Mr. Kruger had in his
earlier post here:
https://groups.google.com/a/isocpp.org/d/msg/std-proposals/frHziD8lCa4/J_4ZMtl5AwAJ
>
> The snippet is attached.
A slightly revised snippet is attached which more clearly shows
what is shorthand is.
[snip]
> IIUC, what Mr. Krugler was proposing is that:
>
> using MyClass::MyEnum;
>
> would simply be shorthand for:
>
> constexpr auto A=MyClass::A;
> constexpr auto B=MyClass::B;
> constexpr auto C=MyClass::C;
> constexpr auto D=MyClass::D;
>
> What's wrong with simply providing a shorthand for something
> already possible?
--
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/og29ch%241ar%241%40blaine.gmane.org.
--------------5015A74B61A1FE6DC4299558
Content-Type: text/x-c++src;
name="implicit_enum_lookup_ambiguity_struct.cpp"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="implicit_enum_lookup_ambiguity_struct.cpp"
//Purpose:
// By compiling, demonstrate ambiguity in code from:
/*
https://groups.google.com/a/isocpp.org/d/msg/std-proposals/frHziD8lCa4/mckYIw0mAgAJ
*/
//===============================
#include <cassert>
struct MyClass
{
enum MyEnum { A, B, C, D };
void DoSomething(const MyEnum Enum)
{
assert(Enum == A);
}
};
#define USE_VAR
#ifdef USE_VAR
MyClass::MyEnum B = MyClass::MyEnum::A;
#endif
void Function(MyClass& myClass)
{
myClass.DoSomething(MyClass::A); // Current way to access the enum
//#define USING_PROPOSED
#ifdef USING_PROPOSED
using MyClass::B;
#else
// using MyClass::MyEnum to provide access to all enumerators.
// Equivalent to:
constexpr auto A=MyClass::A;
constexpr auto B=MyClass::B;
constexpr auto C=MyClass::C;
constexpr auto D=MyClass::D;
#endif
myClass.DoSomething(B); // New way to access the enum?
}
int main()
{
MyClass myClass;
Function(myClass);
return 0;
}
//Result:
/*
-*- mode: compilation; default-directory: "~/prog_dev/c++/standard/proposals/" -*-
Compilation started at Tue May 23 15:09:50
make -k run
/home/evansl/dwnlds/llvm/3.9/prebuilt/clang+llvm-3.9.0-x86_64-linux-gnu-ubuntu-16.04/bin/clang++ -c -O0 -stdlib=libc++ -std=c++1z -ftemplate-backtrace-limit=0 -fdiagnostics-show-template-tree -fno-elide-type -fmacro-backtrace-limit=0 -ftemplate-depth=200 implicit_enum_lookup_ambiguity_struct.cpp -MMD -o /tmp/build/clangxx3_9_pkg/c++/standard/proposals/implicit_enum_lookup_ambiguity_struct.o
implicit_enum_lookup_ambiguity_struct.cpp:26:24: error: using declaration cannot refer to class member
using MyClass::B;
~~~~~~~~~^
implicit_enum_lookup_ambiguity_struct.cpp:26:9: note: use a constexpr variable instead
using MyClass::B;
^~~~~
constexpr auto B =
1 error generated.
/home/evansl/prog_dev/root.imk:172: recipe for target '/tmp/build/clangxx3_9_pkg/c++/standard/proposals/implicit_enum_lookup_ambiguity_struct.o' failed
make: *** [/tmp/build/clangxx3_9_pkg/c++/standard/proposals/implicit_enum_lookup_ambiguity_struct.o] Error 1
make: Target 'run' not remade because of errors.
Compilation exited abnormally with code 2 at Tue May 23 15:09:50
*/
--------------5015A74B61A1FE6DC4299558--
.
Author: thealbig@gmail.com
Date: Tue, 23 May 2017 15:07:43 -0700 (PDT)
Raw View
------=_Part_3354_683596224.1495577263343
Content-Type: multipart/alternative;
boundary="----=_Part_3355_1938082536.1495577263343"
------=_Part_3355_1938082536.1495577263343
Content-Type: text/plain; charset="UTF-8"
>
> > would simply be shorthand for:
> >
> > constexpr auto A=MyClass::A;
> > constexpr auto B=MyClass::B;
> > constexpr auto C=MyClass::C;
> > constexpr auto D=MyClass::D;
> >
> > What's wrong with simply providing a shorthand for something
> > already possible?
>
Because consider the above example again:
Pin.Level = High; //spare me CPinClass::CAsOutput::ePinLevel::
Pin.Speed = High; //spare me CPinClass::CAsOutput::ePinSpeed::
"This is perfectly readable code, yet the High for the Pin-level is just a
1 while the High for the Speed is maybe a 3 because a Pin might support 4
different toggle speeds."
Bringing "High" twice in the namespace is wrong, wont compile and is
inherently problematic and defeats the whole purpose of this idea.
If there were never name colisions you wouldnt need to put the enums in the
class scopes in the first place.So bringing every enum to the local
namespace by manual importing them is the same as declaring them in the
namespace.
Nothing gained.
This is why i want a context aware lookup in the right namepsace/scope if
an enum is expected. And JUST the enum thats expected at this place.
--
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/990a57b9-d56f-4220-82c1-8315bce38ee1%40isocpp.org.
------=_Part_3355_1938082536.1495577263343
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">> would si=
mply be shorthand for:
<br>>=20
<br>> =C2=A0 =C2=A0constexpr auto A=3DMyClass::A;
<br>> =C2=A0 =C2=A0constexpr auto B=3DMyClass::B;
<br>> =C2=A0 =C2=A0constexpr auto C=3DMyClass::C;
<br>> =C2=A0 =C2=A0constexpr auto D=3DMyClass::D;
<br>>=20
<br>> What's wrong with simply providing a shorthand for something
<br>> already possible?
<br></blockquote><div><br>Because consider the above example again:<br><br>=
Pin.Level =3D High;=C2=A0=C2=A0 //spare me CPinClass::CAsOutput::ePinLevel:=
:<br><div dir=3D"ltr">Pin.Speed =3D High; //spare me CPinClass::<wbr>CAsOut=
put::ePinSpeed::<br><br>"This
is perfectly readable code, yet the High for the Pin-level is just a 1=20
while the High for the Speed is maybe a 3 because a Pin might support 4=20
different toggle speeds."<br><br>Bringing "High" twice in th=
e namespace is wrong, wont compile and is inherently problematic and defeat=
s the whole purpose of this idea.<br>If there were never name colisions you=
wouldnt need to put the enums in the class scopes in the first place.So br=
inging every enum to the local namespace by manual importing them is the sa=
me as declaring them in the namespace. <br>Nothing gained.<br>This is why i=
want a context aware lookup in the right namepsace/scope if an enum is exp=
ected. And JUST the enum thats expected at this place.<br></div><br>=C2=A0<=
/div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/990a57b9-d56f-4220-82c1-8315bce38ee1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/990a57b9-d56f-4220-82c1-8315bce38ee1=
%40isocpp.org</a>.<br />
------=_Part_3355_1938082536.1495577263343--
------=_Part_3354_683596224.1495577263343--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 23 May 2017 15:07:57 -0700 (PDT)
Raw View
------=_Part_3847_768126515.1495577277450
Content-Type: multipart/alternative;
boundary="----=_Part_3848_489146734.1495577277450"
------=_Part_3848_489146734.1495577277450
Content-Type: text/plain; charset="UTF-8"
On Tuesday, May 23, 2017 at 3:19:55 PM UTC-4, thea...@gmail.com wrote:
>
>
>> We've already explained where the problem is: if the enumerator has the
>> same name as an existing variable. Right now, that has a specific meaning.
>> To do what you want requires either changing that meaning or making your
>> feature not work in every case.
>>
>> That's why I suggest using specific syntax to express this, instead of
>> using just an enumerator name.
>>
>
> Sry Nicol that i am so complicated, can you write up a small snippet to
> illustrate this?
> I explicitly changed my opinion to invoke this feature only if all other
> options fail to compile - meaning the name lookup found no option. Only
> then lookup in the expected enum namespace.
>
And like I said, this means your feature doesn't work in every case. You
have to now dance around enumerators that happen to match existing
identifiers.
If you just use explicit syntax for it, then not only is defining the
behavior easier (since it's a new construct), the user doesn't have to
worry about such conflicts. And remember: one of the main purposes of `enum
class`es was to *prevent* such name collisions. This is why some modern C++
coding styles no longer suggest that you make enumerator names ALL_CAPS.
Because we don't have to anymore.
If you use an explicit syntax to invoke the behavior, then you don't have
to concern yourself about conflicts. You just say `enum whatever`, and
you're done.
--
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/011be2f5-5c9c-46f8-b0d6-505a087a4829%40isocpp.org.
------=_Part_3848_489146734.1495577277450
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, May 23, 2017 at 3:19:55 PM UTC-4, thea=
....@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br>=
We've already explained where the problem is: if the enumerator has the=
same name as an existing variable. Right now, that has a specific meaning.=
To do what you want requires either changing that meaning or making your f=
eature not work in every case.<br><br>That's why I suggest using specif=
ic syntax to express this, instead of using just an enumerator name.</div><=
/div></blockquote><div><br>Sry Nicol that i am so complicated, can you writ=
e up a small snippet to illustrate this?=C2=A0 <br>I explicitly changed my =
opinion to invoke this feature only if all other options fail to compile - =
meaning the name lookup found no option. Only then lookup in the expected e=
num namespace.<br></div></div></blockquote><div><br>And like I said, this m=
eans your feature doesn't work in every case. You have to now dance aro=
und enumerators that happen to match existing identifiers.<br><br>If you ju=
st use explicit syntax for it, then not only is defining the behavior easie=
r (since it's a new construct), the user doesn't have to worry abou=
t such conflicts. And remember: one of the main purposes of `enum class`es =
was to <i>prevent</i> such name collisions. This is why some modern C++ cod=
ing styles no longer suggest that you make enumerator names ALL_CAPS. Becau=
se we don't have to anymore.<br><br>If you use an explicit syntax to in=
voke the behavior, then you don't have to concern yourself about confli=
cts. You just say `enum whatever`, and you're done.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/011be2f5-5c9c-46f8-b0d6-505a087a4829%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/011be2f5-5c9c-46f8-b0d6-505a087a4829=
%40isocpp.org</a>.<br />
------=_Part_3848_489146734.1495577277450--
------=_Part_3847_768126515.1495577277450--
.
Author: thealbig@gmail.com
Date: Tue, 23 May 2017 15:49:52 -0700 (PDT)
Raw View
------=_Part_3845_1450847461.1495579792139
Content-Type: multipart/alternative;
boundary="----=_Part_3846_2061647766.1495579792139"
------=_Part_3846_2061647766.1495579792139
Content-Type: text/plain; charset="UTF-8"
Am Mittwoch, 24. Mai 2017 00:07:57 UTC+2 schrieb Nicol Bolas:
>
>
> You have to now dance around enumerators that happen to match existing
> identifiers.
>
> And remember: one of the main purposes of `enum class`es was to *prevent*
> such name collisions. This is why some modern C++ coding styles no longer
> suggest that you make enumerator names ALL_CAPS. Because we don't have to
> anymore.
>
>
I am not sure if you have in mind when the sugested feature turns on. I
repeat again, that the implicit lookup within the expected enum namespace
shall be the absolute last option if nothing else fits. This will preserve
existing behavior perfectly and handles shadowing the way it is handled now.
Matching identifier names do not colide because when an Enum1::A is
expected (as argument or in an asignment) another identifier like Enum2::A
is never considered automatically, just Enum1 (due to context awareness
that an Enum1 is expected!).
I agree that the enum class is made for avoiding those collisions. This
does not mean that you have to pay the penalty to write out the Enum-Type
everytime you want to access an identifier. The compiler knows which type
is expected, so dont bother the programmer.
I repeat again that i do NOT want to make every enum member available in
the current namespace. This shall be highly context aware
--
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/ab99d417-b6b6-474f-87ac-c401c2382bc7%40isocpp.org.
------=_Part_3846_2061647766.1495579792139
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>Am Mittwoch, 24. Mai 2017 00:07:57 UTC+2 schrieb Nicol=
Bolas:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br>Yo=
u have to now dance around enumerators that happen to match existing identi=
fiers.<br><div><br>And remember: one of the main purposes of `enum class`es=
was to <i>prevent</i> such name collisions. This is why some modern C++ co=
ding styles no longer suggest that you make enumerator names ALL_CAPS. Beca=
use we don't have to anymore.<br><br></div></div></blockquote><div><br>=
I am not sure if you have in mind when the sugested feature turns on. I rep=
eat again, that the implicit lookup within the expected enum namespace shal=
l be the absolute last option if nothing else fits. This will preserve exis=
ting behavior perfectly and handles shadowing the way it is handled now.<br=
>Matching identifier names do not colide because when an Enum1::A is expect=
ed (as argument or in an asignment) another identifier like Enum2::A is nev=
er considered automatically, just Enum1 (due to context awareness that an E=
num1 is expected!).<br>I agree that the enum class is made for avoiding tho=
se collisions. This does not mean that you have to pay the penalty to write=
out the Enum-Type everytime you want to access an identifier. The compiler=
knows which type is expected, so dont bother the programmer.<br><br>I repe=
at again that i do NOT want to make every enum member available in the curr=
ent namespace. This shall be highly context aware<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/ab99d417-b6b6-474f-87ac-c401c2382bc7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ab99d417-b6b6-474f-87ac-c401c2382bc7=
%40isocpp.org</a>.<br />
------=_Part_3846_2061647766.1495579792139--
------=_Part_3845_1450847461.1495579792139--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 23 May 2017 16:36:10 -0700 (PDT)
Raw View
------=_Part_3817_1404731025.1495582570315
Content-Type: multipart/alternative;
boundary="----=_Part_3818_2068420599.1495582570315"
------=_Part_3818_2068420599.1495582570315
Content-Type: text/plain; charset="UTF-8"
On Tuesday, May 23, 2017 at 6:49:52 PM UTC-4, thea...@gmail.com wrote:
>
>
> Am Mittwoch, 24. Mai 2017 00:07:57 UTC+2 schrieb Nicol Bolas:
>>
>>
>> You have to now dance around enumerators that happen to match existing
>> identifiers.
>>
>> And remember: one of the main purposes of `enum class`es was to *prevent*
>> such name collisions. This is why some modern C++ coding styles no longer
>> suggest that you make enumerator names ALL_CAPS. Because we don't have to
>> anymore.
>>
>>
> I am not sure if you have in mind when the sugested feature turns on. I
> repeat again, that the implicit lookup within the expected enum namespace
> shall be the absolute last option if nothing else fits. This will preserve
> existing behavior perfectly and handles shadowing the way it is handled now.
>
I'm not talking about preserving existing behavior. I'm talking about doing
what the user wants:
enum class A
{
name1,
name2,
};
A name2 = A::name1;
A a = name2;
We agree that this is the behavior that the code would have had before.
However, it's *not* the behavior the user wanted. The user wanted
`A::name2` in `a`, but they can't get that because the compiler mistook it
for another name. So they have to spell out the name.
By doing this:
A a = enum name2;
We make to clear to *everyone* exactly what the code is doing. Users don't
have to dance around using names. A raw identifier is only an enumerator
name if it is actually available as an enumerator name. `enum identifier`
means "look up the identifier based on the context.
My idea also continues to make this not work:
int name2 = 5;
A a = name2;
It's not clear what your "absolute last option if nothing else fits" rule
means in this context. You might want it to compile, using `A::name2`. But
to a casual reader of this code, that's *not* what it looks like it's
doing. It looks like it's sticking 5 in there, which would normally be a
compile error due to implicit conversion of an integer to an enum.
I say that this code should *continue* to be a compile error.
We allow the user to express their intent, while simultaneously preserving
the integrity of the feature.
--
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/72f6ffd9-dde7-46cf-a117-3144754a8d63%40isocpp.org.
------=_Part_3818_2068420599.1495582570315
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, May 23, 2017 at 6:49:52 PM UTC-4, thea=
....@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><br>Am Mittwoch, 24. Mai 2017 00:07:57 UTC+2 schrieb Nicol Bolas:<=
blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>You have to now=
dance around enumerators that happen to match existing identifiers.<br><di=
v><br>And remember: one of the main purposes of `enum class`es was to <i>pr=
event</i> such name collisions. This is why some modern C++ coding styles n=
o longer suggest that you make enumerator names ALL_CAPS. Because we don=
9;t have to anymore.<br><br></div></div></blockquote><div><br>I am not sure=
if you have in mind when the sugested feature turns on. I repeat again, th=
at the implicit lookup within the expected enum namespace shall be the abso=
lute last option if nothing else fits. This will preserve existing behavior=
perfectly and handles shadowing the way it is handled now.<br></div></div>=
</blockquote><div><br>I'm not talking about preserving existing behavio=
r. I'm talking about doing what the user wants:<br><br><div style=3D"ba=
ckground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); borde=
r-style: solid; border-width: 1px; overflow-wrap: break-word;" class=3D"pre=
ttyprint"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">enum</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">class</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> A<br></span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br>=C2=A0 name1</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br>=C2=A0 name2</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">};</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br><br>A name2 </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
A</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">name1</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br><br>A a </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> name2</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br></span></div></code></div><br>We agree tha=
t this is the behavior that the code would have had before. However, it'=
;s <i>not</i> the behavior the user wanted. The user wanted `A::name2` in `=
a`, but they can't get that because the compiler mistook it for another=
name. So they have to spell out the name.<br><br>By doing this:<br><br><di=
v style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187=
, 187); border-style: solid; border-width: 1px; overflow-wrap: break-word;"=
class=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subprettyp=
rint"><span style=3D"color: #000;" class=3D"styled-by-prettify">A a </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">enum</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> name2</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span></div></code></div><br>We make to clear =
to <i>everyone</i> exactly what the code is doing. Users don't have to =
dance around using names. A raw identifier is only an enumerator name if it=
is actually available as an enumerator name. `enum identifier` means "=
;look up the identifier based on the context.<br><br>My idea also continues=
to make this not work:<br><br><div style=3D"background-color: rgb(250, 250=
, 250); border-color: rgb(187, 187, 187); border-style: solid; border-width=
: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><code class=3D"pre=
ttyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=
=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> name2 </span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">5<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br>A a </span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> name2</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">;</span></div></code></div><br>I=
t's not clear what your "absolute last option if nothing else fits=
" rule means in this context. You might want it to compile, using `A::=
name2`. But to a casual reader of this code, that's <i>not</i> what it =
looks like it's doing. It looks like it's sticking 5 in there, whic=
h would normally be a compile error due to implicit conversion of an intege=
r to an enum.<br><br>I say that this code should <i>continue</i> to be a co=
mpile error.<br><br>We allow the user to express their intent, while simult=
aneously preserving the integrity of the feature.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/72f6ffd9-dde7-46cf-a117-3144754a8d63%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/72f6ffd9-dde7-46cf-a117-3144754a8d63=
%40isocpp.org</a>.<br />
------=_Part_3818_2068420599.1495582570315--
------=_Part_3817_1404731025.1495582570315--
.
Author: thealbig@gmail.com
Date: Tue, 23 May 2017 17:48:45 -0700 (PDT)
Raw View
------=_Part_3843_251663740.1495586925187
Content-Type: multipart/alternative;
boundary="----=_Part_3844_1425311411.1495586925187"
------=_Part_3844_1425311411.1495586925187
Content-Type: text/plain; charset="UTF-8"
I'm talking about doing what the user wants:
>
> enum class A
> {
> name1,
> name2,
> };
>
> A name2 = A::name1;
>
> A a = name2;
>
> The user wanted `A::name2` in `a`, but they can't get that because the
> compiler mistook it for another name. So they have to spell out the name.
>
Ahahaha, now i get what you want :-D Thanks A LOT :-)
Well lets dicuss it. Its a fact that this code does currently compile and
its also a fact that my proposal would not change its behavior. However you
are right thats impossible now to asign name2 in the meaning of A::name2 by
such implicit namespace deduction. (however its still possible the old way
which is a fine alternative imho)
My initial thought was: whoever writes such a BS deserves it ^_^. But
taking it seriously i have to think about it:
1) The issue is more fundamental: the user can use the name of a enum
member to create a variable that represents another enum member of the same
type. -> I think such practice should throw a warning. If not, its an
oversight allready!
2) Its a shadowing problem where the intent of the user is actually NOT
clear. You assume that `A::name2` in `a` is what you wanted because you
know what you wanted; but when i read the code i would have interpretet it
differently (honestly), because the notion of such a code is a total brain
fart. -> i think that assignment should throw a "Variable name2 shadows
A::name2" warning which would be totally appropiate.
I am very much for warnings at this point (for both!). I dont see this is
an immediate threat to the idea. This situation is something that should be
avoided in the code by any means and there is no reason why the compiler
should not complain about this.
Your second problem example has a bit more weight to me since i agree that
this is a problem reading the code. I have no current solution to this
except for debating if this code should really be an error. I totally get
why you want it to be an error and i also think that this cant be treated
with a warning, since there is no shadowing going on and there is a type
missmatch in contrast to the first example. So formally the code would be
ok...
My problem with your solution is that i can see it becomes inconsistent
over the code.
See.. writing the enum in front of every identifier is ok, if you shorten
the quest for the right namespace with it...
However if the enum is already close to the namespace (like in your
example) its actually faster to write A::name1 instead of enum name1. This
leads to inconsistent use of the feature across the code which i wouldnt
like.
You also you put the syntax of a variable declaration on the right hand
side of an expression. Poor beginners.
What about enum::name1 ?
So use enum:: as context aware enum namespace lookup.?
I am not sure. I would like to hear from others what they think about this
case. I would really like to discuss if
int name2 = 5;
A a = name2;
should be an error or not. I think it about this way: this example is
perfect to show a bad practice anyway. So i would call this an edge case.
Now the question stands (at least for me) if a bad practice edge case
should have such impact on the useability and consistency of the proposed
feature. [writing enum or enum:: everywhere instead of nothing]
The same becomes true for overloaded functions btw:
int Foo(A a) {}
int Foo(int a) {}
now call Foo(name2) // ambiguity error.
Its my opinion to rather deal with an ambiguity error instead of having to
write a special syntax to shorten the namespace::search::for::the::Enum
everytime even its not ambiguous because most of the time its not.
But i see why this would be an ok compromise, so i am not against it, but i
dont favor it.
--
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/5c87e5b3-6d6f-4532-8d7d-eb2f1a33a68a%40isocpp.org.
------=_Part_3844_1425311411.1495586925187
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">=C2=A0I'm talking about doing what the user wants:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br><div=
style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);b=
order-style:solid;border-width:1px"><code><div><span style=3D"color:#008">e=
num</span><span style=3D"color:#000"> </span><span style=3D"color:#008">cla=
ss</span><span style=3D"color:#000"> A<br></span><span style=3D"color:#660"=
>{</span><span style=3D"color:#000"><br>=C2=A0 name1</span><span style=3D"c=
olor:#660">,</span><span style=3D"color:#000"><br>=C2=A0 name2</span><span =
style=3D"color:#660">,</span><span style=3D"color:#000"><br></span><span st=
yle=3D"color:#660">};</span><span style=3D"color:#000"><br><br>A name2 </sp=
an><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> A</span=
><span style=3D"color:#660">::</span><span style=3D"color:#000">name1</span=
><span style=3D"color:#660">;</span><span style=3D"color:#000"><br><br>A a =
</span><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> nam=
e2</span><span style=3D"color:#660">;</span><span style=3D"color:#000"><br>=
</span></div></code></div><br>The user wanted `A::name2` in `a`, but they c=
an't get that because the compiler mistook it for another name. So they=
have to spell out the name.<br></div></div></blockquote><div><br>Ahahaha, =
now i get what you want :-D=C2=A0 Thanks=C2=A0 A LOT :-)<br>Well lets dicus=
s it. Its a fact that this code does currently compile and its also a fact =
that my proposal would not change its behavior. However you are right thats=
impossible now to asign name2 in the meaning of A::name2 by such implicit =
namespace deduction. (however its still possible the old way which is a fin=
e alternative imho)<br>My initial thought was: whoever writes such a BS des=
erves it ^_^. But taking it seriously i have to think about it:<br>1) The i=
ssue is more fundamental: the user can use the name of a enum member to cre=
ate a variable that represents another enum member of the same type.=C2=A0=
=C2=A0 -> I think such practice should throw a warning.=C2=A0 If not, it=
s an oversight allready! <br>2) Its a shadowing problem where the intent of=
the user is actually NOT clear. You assume that `A::name2` in `a` is what =
you wanted because you know what you wanted; but when i read the code i wou=
ld have interpretet it differently (honestly), because the notion of such a=
code is a total brain fart.=C2=A0 -> i think that assignment should thr=
ow a "Variable name2 shadows A::name2" warning which would be tot=
ally appropiate.<br><br>I am very much for warnings at this point (for both=
!). I dont see this is an immediate threat to the idea. This situation is s=
omething that should be avoided in the code by any means and there is no re=
ason why the compiler should not complain about this.<br><br>Your second pr=
oblem example has a bit more weight to me since i agree that this is a prob=
lem reading the code. I have no current solution to this except for debatin=
g if this code should really be an error. I totally get why you want it to =
be an error and i also think that this cant be treated with a warning, sinc=
e there is no shadowing going on and there is a type missmatch in contrast =
to the first example. So formally the code would be ok...<br><br>My problem=
with your solution is that i can see it becomes inconsistent over the code=
..<br>See.. writing the enum in front of every identifier is ok, if you shor=
ten the quest for the right namespace with it...<br>However if the enum is =
already close to the namespace (like in your example) its actually faster t=
o write A::name1 instead of enum name1. This leads to inconsistent use of t=
he feature across the code which i wouldnt like.<br>You also you put the sy=
ntax of a variable declaration on the right hand side of an expression. Poo=
r beginners.<br><br>What about enum::name1 ?=C2=A0 <br>So use enum:: as con=
text aware enum namespace lookup.?<br><br>I am not sure. I would like to he=
ar from others what they think about this case. I would really like to disc=
uss if<br><div style=3D"background-color:rgb(250,250,250);border-color:rgb(=
187,187,187);border-style:solid;border-width:1px"><code><div><span style=3D=
"color:#008">int</span><span style=3D"color:#000"> name2 </span><span style=
=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><span style=3D=
"color:#066">5</span><span style=3D"color:#660">;</span><span style=3D"colo=
r:#000"><br>A a </span><span style=3D"color:#660">=3D</span><span style=3D"=
color:#000"> name2</span><span style=3D"color:#660">;</span></div></code></=
div>should be an error or not. I think it about this way: this example is p=
erfect to show a bad practice anyway. So i would call this an edge case.<br=
>Now the question stands (at least for me) if a bad practice edge case shou=
ld have such impact on the useability and consistency of the proposed featu=
re. [writing enum or enum:: everywhere instead of nothing]<br><br>The same =
becomes true for overloaded functions btw:<br><br>int Foo(A a) {}<br>int Fo=
o(int a) {}<br><br>now call Foo(name2) //=C2=A0 ambiguity error.<br><br>Its=
my opinion to rather deal with an ambiguity error instead of having to wri=
te a special syntax to shorten the namespace::search::for::the::Enum everyt=
ime even its not ambiguous because most of the time its not.<br>But i see w=
hy this would be an ok compromise, so i am not against it, but i dont favor=
it.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/5c87e5b3-6d6f-4532-8d7d-eb2f1a33a68a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5c87e5b3-6d6f-4532-8d7d-eb2f1a33a68a=
%40isocpp.org</a>.<br />
------=_Part_3844_1425311411.1495586925187--
------=_Part_3843_251663740.1495586925187--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 23 May 2017 18:41:06 -0700 (PDT)
Raw View
------=_Part_3696_1240750469.1495590066737
Content-Type: multipart/alternative;
boundary="----=_Part_3697_1692847289.1495590066737"
------=_Part_3697_1692847289.1495590066737
Content-Type: text/plain; charset="UTF-8"
On Tuesday, May 23, 2017 at 8:48:45 PM UTC-4, thea...@gmail.com wrote:
>
> I'm talking about doing what the user wants:
>
>>
>> enum class A
>> {
>> name1,
>> name2,
>> };
>>
>> A name2 = A::name1;
>>
>> A a = name2;
>>
>> The user wanted `A::name2` in `a`, but they can't get that because the
>> compiler mistook it for another name. So they have to spell out the name.
>>
>
> Ahahaha, now i get what you want :-D Thanks A LOT :-)
> Well lets dicuss it. Its a fact that this code does currently compile and
> its also a fact that my proposal would not change its behavior. However you
> are right thats impossible now to asign name2 in the meaning of A::name2 by
> such implicit namespace deduction. (however its still possible the old way
> which is a fine alternative imho)
> My initial thought was: whoever writes such a BS deserves it ^_^. But
> taking it seriously i have to think about it:
> 1) The issue is more fundamental: the user can use the name of a enum
> member to create a variable that represents another enum member of the same
> type. -> I think such practice should throw a warning. If not, its an
> oversight allready!
> 2) Its a shadowing problem where the intent of the user is actually NOT
> clear. You assume that `A::name2` in `a` is what you wanted because you
> know what you wanted; but when i read the code i would have interpretet it
> differently (honestly), because the notion of such a code is a total brain
> fart. -> i think that assignment should throw a "Variable name2 shadows
> A::name2" warning which would be totally appropiate.
>
> I am very much for warnings at this point (for both!). I dont see this is
> an immediate threat to the idea. This situation is something that should be
> avoided in the code by any means and there is no reason why the compiler
> should not complain about this.
>
> Your second problem example has a bit more weight to me since i agree that
> this is a problem reading the code. I have no current solution to this
> except for debating if this code should really be an error. I totally get
> why you want it to be an error and i also think that this cant be treated
> with a warning, since there is no shadowing going on and there is a type
> missmatch in contrast to the first example. So formally the code would be
> ok...
>
> My problem with your solution is that i can see it becomes inconsistent
> over the code.
> See.. writing the enum in front of every identifier is ok, if you shorten
> the quest for the right namespace with it...
> However if the enum is already close to the namespace (like in your
> example) its actually faster to write A::name1 instead of enum name1. This
> leads to inconsistent use of the feature across the code which i wouldnt
> like.
>
But... your version leads to inconsistent use of the feature too, due to
name conflicts. At least with explicit syntax, the choice of when to use it
is based purely on what the writer of the code feels is most clear. Yours
has to be used based on name conflicts, as well as what makes things more
clear.
Also, these abbreviated names can't be used everywhere anyway, so total
consistency just isn't going to happen. There are cases where you need to
name an enumerator where there is no context available. For example:
int i = (int)enumerator;
I imagine that for comparisons, you'd also need to spell out the enumerator
name. Especially if the identifier comes before the expression that
determines its type:
if(enumerator < enumValue)
To do otherwise would require the compiler to implement look-ahead. It
would have to figure out the type of the `enumValue` expression before it
could decide what `enumerator` would resolve to. And look-ahead is
generally considered a bad thing.
Consistency isn't going to happen, so I don't see it as a detriment to
explicit syntax.
You also you put the syntax of a variable declaration on the right hand
> side of an expression. Poor beginners.
>
First, `enum` is not used to declare variables. Well, I guess it is, but
beginners shouldn't be taught that it is. For beginners, `enum`, `class`,
`union`, and the like are *type* declarations, not variable declarations.
Second, they're C++ beginners. They already have to figure out that `[]()`
is somehow a function. This oddity wouldn't even register for them ;)
What about enum::name1 ?
> So use enum:: as context aware enum namespace lookup.?
>
The exact spelling is more or less irrelevant to me. I'm interested in not
having an identifier have a new meaning based on non-local context.
I am not sure. I would like to hear from others what they think about this
> case. I would really like to discuss if
> int name2 = 5;
> A a = name2;
> should be an error or not.
>
I think the important thing is not whether that specific code should be an
error. It's whether *this* code should be an error:
void function(A a) {...}
//Twelve file and 5,000 lines of code later
int name2 = 5;
function(name2);
If the only code a user sees is the two lines at the bottom, and `function`
(and its associated enumeration) is declared a long way away, the reader of
those two lines has every reason to assume that `name2` refers to the local
variable, not some enumerator.
> I think it about this way: this example is perfect to show a bad practice
> anyway. So i would call this an edge case.
> Now the question stands (at least for me) if a bad practice edge case
> should have such impact on the useability and consistency of the proposed
> feature. [writing enum or enum:: everywhere instead of nothing]
>
> The same becomes true for overloaded functions btw:
>
> int Foo(A a) {}
> int Foo(int a) {}
>
> now call Foo(name2) // ambiguity error.
>
> Its my opinion to rather deal with an ambiguity error instead of having to
> write a special syntax to shorten the namespace::search::for::the::Enum
> everytime even its not ambiguous because most of the time its not.
> But i see why this would be an ok compromise, so i am not against it, but
> i dont favor it.
>
--
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/cac6c99d-16b2-42d1-8aec-6f73f5903e73%40isocpp.org.
------=_Part_3697_1692847289.1495590066737
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, May 23, 2017 at 8:48:45 PM UTC-4, thea...@gmai=
l.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
=C2=A0I'm talking about doing what the user wants:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div><br><div style=3D"background-c=
olor:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;bord=
er-width:1px"><code><div><span style=3D"color:#008">enum</span><span style=
=3D"color:#000"> </span><span style=3D"color:#008">class</span><span style=
=3D"color:#000"> A<br></span><span style=3D"color:#660">{</span><span style=
=3D"color:#000"><br>=C2=A0 name1</span><span style=3D"color:#660">,</span><=
span style=3D"color:#000"><br>=C2=A0 name2</span><span style=3D"color:#660"=
>,</span><span style=3D"color:#000"><br></span><span style=3D"color:#660">}=
;</span><span style=3D"color:#000"><br><br>A name2 </span><span style=3D"co=
lor:#660">=3D</span><span style=3D"color:#000"> A</span><span style=3D"colo=
r:#660">::</span><span style=3D"color:#000">name1</span><span style=3D"colo=
r:#660">;</span><span style=3D"color:#000"><br><br>A a </span><span style=
=3D"color:#660">=3D</span><span style=3D"color:#000"> name2</span><span sty=
le=3D"color:#660">;</span><span style=3D"color:#000"><br></span></div></cod=
e></div><br>The user wanted `A::name2` in `a`, but they can't get that =
because the compiler mistook it for another name. So they have to spell out=
the name.<br></div></div></blockquote><div><br>Ahahaha, now i get what you=
want :-D=C2=A0 Thanks=C2=A0 A LOT :-)<br>Well lets dicuss it. Its a fact t=
hat this code does currently compile and its also a fact that my proposal w=
ould not change its behavior. However you are right thats impossible now to=
asign name2 in the meaning of A::name2 by such implicit namespace deductio=
n. (however its still possible the old way which is a fine alternative imho=
)<br>My initial thought was: whoever writes such a BS deserves it ^_^. But =
taking it seriously i have to think about it:<br>1) The issue is more funda=
mental: the user can use the name of a enum member to create a variable tha=
t represents another enum member of the same type.=C2=A0=C2=A0 -> I thin=
k such practice should throw a warning.=C2=A0 If not, its an oversight allr=
eady! <br>2) Its a shadowing problem where the intent of the user is actual=
ly NOT clear. You assume that `A::name2` in `a` is what you wanted because =
you know what you wanted; but when i read the code i would have interpretet=
it differently (honestly), because the notion of such a code is a total br=
ain fart.=C2=A0 -> i think that assignment should throw a "Variable=
name2 shadows A::name2" warning which would be totally appropiate.<br=
><br>I am very much for warnings at this point (for both!). I dont see this=
is an immediate threat to the idea. This situation is something that shoul=
d be avoided in the code by any means and there is no reason why the compil=
er should not complain about this.<br><br>Your second problem example has a=
bit more weight to me since i agree that this is a problem reading the cod=
e. I have no current solution to this except for debating if this code shou=
ld really be an error. I totally get why you want it to be an error and i a=
lso think that this cant be treated with a warning, since there is no shado=
wing going on and there is a type missmatch in contrast to the first exampl=
e. So formally the code would be ok...<br><br>My problem with your solution=
is that i can see it becomes inconsistent over the code.<br>See.. writing =
the enum in front of every identifier is ok, if you shorten the quest for t=
he right namespace with it...<br>However if the enum is already close to th=
e namespace (like in your example) its actually faster to write A::name1 in=
stead of enum name1. This leads to inconsistent use of the feature across t=
he code which i wouldnt like.<br></div></div></blockquote><div><br>But... y=
our version leads to inconsistent use of the feature too, due to name confl=
icts. At least with explicit syntax, the choice of when to use it is based =
purely on what the writer of the code feels is most clear. Yours has to be =
used based on name conflicts, as well as what makes things more clear.<br><=
br>Also, these abbreviated names can't be used everywhere anyway, so to=
tal consistency just isn't going to happen. There are cases where you n=
eed to name an enumerator where there is no context available. For example:=
<br><br><div style=3D"background-color: rgb(250, 250, 250); border-color: r=
gb(187, 187, 187); border-style: solid; border-width: 1px; overflow-wrap: b=
reak-word;" class=3D"prettyprint"><code class=3D"prettyprint"><div class=3D=
"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">=
int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> i </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">enumerator</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span></div></code></div><br>I imagine that for c=
omparisons, you'd also need to spell out the enumerator name. Especiall=
y if the identifier comes before the expression that determines its type:<b=
r><br><div style=3D"background-color: rgb(250, 250, 250); border-color: rgb=
(187, 187, 187); border-style: solid; border-width: 1px; overflow-wrap: bre=
ak-word;" class=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"s=
ubprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">if=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">enumerator </span><=
span style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> enumValue</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">)</span></div></code></d=
iv><br>To do otherwise would require the compiler to implement look-ahead. =
It would have to figure out the type of the `enumValue` expression before i=
t could decide what `enumerator` would resolve to. And look-ahead is genera=
lly considered a bad thing.<br><br>Consistency isn't going to happen, s=
o I don't see it as a detriment to explicit syntax.<br><br></div><block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>You also you p=
ut the syntax of a variable declaration on the right hand side of an expres=
sion. Poor beginners.<br></div></div></blockquote><div><br>First, `enum` is=
not used to declare variables. Well, I guess it is, but beginners shouldn&=
#39;t be taught that it is. For beginners, `enum`, `class`, `union`, and th=
e like are <i>type</i> declarations, not variable declarations.<br><br>Seco=
nd, they're C++ beginners. They already have to figure out that `[]()` =
is somehow a function. This oddity wouldn't even register for them ;)<b=
r><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div>What about enum::name1 ?=C2=A0 <br>So use enum:: as context aware enum =
namespace lookup.?<br></div></div></blockquote><div><br>The exact spelling =
is more or less irrelevant to me. I'm interested in not having an ident=
ifier have a new meaning based on non-local context.<br><br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>I am not sure. I =
would like to hear from others what they think about this case. I would rea=
lly like to discuss if<br><div style=3D"background-color:rgb(250,250,250);b=
order-color:rgb(187,187,187);border-style:solid;border-width:1px"><code><di=
v><span style=3D"color:#008">int</span><span style=3D"color:#000"> name2 </=
span><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> </spa=
n><span style=3D"color:#066">5</span><span style=3D"color:#660">;</span><sp=
an style=3D"color:#000"><br>A a </span><span style=3D"color:#660">=3D</span=
><span style=3D"color:#000"> name2</span><span style=3D"color:#660">;</span=
></div></code></div>should be an error or not.</div></div></blockquote><div=
><br>I think the important thing is not whether that specific code should b=
e an error. It's whether <i>this</i> code should be an error:<br><br><d=
iv style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 18=
7, 187); border-style: solid; border-width: 1px; overflow-wrap: break-word;=
" class=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subpretty=
print"><span style=3D"color: #008;" class=3D"styled-by-prettify">void</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">function</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">A a</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">{...}</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br><br></span><span style=3D"color: #800;" class=3D"styled-by-pr=
ettify">//Twelve file and 5,000 lines of code later</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br><br></span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> name2 </span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"style=
d-by-prettify">5</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
></span><span style=3D"color: #008;" class=3D"styled-by-prettify">function<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">name2</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">);</span></div></code></d=
iv><br>If the only code a user sees is the two lines at the bottom, and `fu=
nction` (and its associated enumeration) is declared a long way away, the r=
eader of those two lines has every reason to assume that `name2` refers to =
the local variable, not some enumerator.<br>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div>I think it about this way=
: this example is perfect to show a bad practice anyway. So i would call th=
is an edge case.<br>Now the question stands (at least for me) if a bad prac=
tice edge case should have such impact on the useability and consistency of=
the proposed feature. [writing enum or enum:: everywhere instead of nothin=
g]<br><br>The same becomes true for overloaded functions btw:<br><br>int Fo=
o(A a) {}<br>int Foo(int a) {}<br><br>now call Foo(name2) //=C2=A0 ambiguit=
y error.<br><br>Its my opinion to rather deal with an ambiguity error inste=
ad of having to write a special syntax to shorten the namespace::search::fo=
r::the::<wbr>Enum everytime even its not ambiguous because most of the time=
its not.<br>But i see why this would be an ok compromise, so i am not agai=
nst it, but i dont favor it.<br></div></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/cac6c99d-16b2-42d1-8aec-6f73f5903e73%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/cac6c99d-16b2-42d1-8aec-6f73f5903e73=
%40isocpp.org</a>.<br />
------=_Part_3697_1692847289.1495590066737--
------=_Part_3696_1240750469.1495590066737--
.
Author: thealbig@gmail.com
Date: Tue, 23 May 2017 19:18:37 -0700 (PDT)
Raw View
------=_Part_3961_593723084.1495592318029
Content-Type: multipart/alternative;
boundary="----=_Part_3962_1617698602.1495592318029"
------=_Part_3962_1617698602.1495592318029
Content-Type: text/plain; charset="UTF-8"
Well you got be turned around on every aspect.
Well..except with the look-ahead part..
if(enum::enumerator < enumValue)
still needs look-ahead to lookup the enum:: part.
And yes, i am sorry that mixed up the variable and type-stuff. shouldnt
happen here. :-|
But i generally agree with you.
Btw: the ambiguity would also be resolved if the namespace would not
completely deduced. Just as an alternative:
1) for a normal enum the namespace is completely deduced. (this also makes
the code above clear, since implicit conversion is ok)
2) for a enum class the namespace is only deduced so far that you still
need to write EnumType::ABC. This is also more along the original intent.
Since the Enum-Name can carry information i would accept that too.
Opinions?
--
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/5117a945-547d-4323-b91a-b51480de4d27%40isocpp.org.
------=_Part_3962_1617698602.1495592318029
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Well you got be turned around on every aspect.<br><br>Well=
...except with the look-ahead part..<br><div style=3D"background-color:rgb(2=
50,250,250);border-color:rgb(187,187,187);border-style:solid;border-width:1=
px"><code><div><span style=3D"color:#008">if</span><span style=3D"color:#66=
0">(enum::</span><span style=3D"color:#000">enumerator </span><span style=
=3D"color:#660"><</span><span style=3D"color:#000"> enumValue</span><spa=
n style=3D"color:#660">)</span></div></code></div>still needs look-ahead to=
lookup the enum:: part.<br>And yes, i am sorry that mixed up the variable =
and type-stuff. shouldnt happen here. :-|<br><br>But i generally agree with=
you.<br><br>Btw: the ambiguity would also be resolved if the namespace wou=
ld not completely deduced. Just as an alternative:<br>1) for a normal enum =
the namespace is completely deduced. (this also makes the code above clear,=
since implicit conversion is ok)<br>2) for a enum class the namespace is o=
nly deduced so far that you still need to write EnumType::ABC.=C2=A0 This i=
s also more along the original intent.<br>Since the Enum-Name can carry inf=
ormation i would accept that too.<br><br>Opinions?<br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/5117a945-547d-4323-b91a-b51480de4d27%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5117a945-547d-4323-b91a-b51480de4d27=
%40isocpp.org</a>.<br />
------=_Part_3962_1617698602.1495592318029--
------=_Part_3961_593723084.1495592318029--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 24 May 2017 10:33:25 -0700 (PDT)
Raw View
------=_Part_4253_1604440355.1495647205264
Content-Type: multipart/alternative;
boundary="----=_Part_4254_2071973091.1495647205264"
------=_Part_4254_2071973091.1495647205264
Content-Type: text/plain; charset="UTF-8"
On Tuesday, May 23, 2017 at 10:18:38 PM UTC-4, thea...@gmail.com wrote:
>
> Well you got be turned around on every aspect.
>
> Well..except with the look-ahead part..
> if(enum::enumerator < enumValue)
> still needs look-ahead to lookup the enum:: part.
>
Well... yes. That's what's wrong; look-ahead is not something we make
compilers do, generally speaking. Even when it means making people write
silly things like this:
auto trailing_return(int a, int b) -> decltype(a + b);
Whereas `enumValue < enum::enumerator` would be able to use the type of the
already parsed expression `enumValue` as the context to determine the
validity of the enumerator.
> And yes, i am sorry that mixed up the variable and type-stuff. shouldnt
> happen here. :-|
>
> But i generally agree with you.
>
> Btw: the ambiguity would also be resolved if the namespace would not
> completely deduced. Just as an alternative:
> 1) for a normal enum the namespace is completely deduced. (this also makes
> the code above clear, since implicit conversion is ok)
> 2) for a enum class the namespace is only deduced so far that you still
> need to write EnumType::ABC. This is also more along the original intent.
> Since the Enum-Name can carry information i would accept that too.
>
> Opinions?
>
--
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/d603024f-3aac-4a26-9548-2e55685afc6d%40isocpp.org.
------=_Part_4254_2071973091.1495647205264
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, May 23, 2017 at 10:18:38 PM UTC-4, thea...@gma=
il.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
Well you got be turned around on every aspect.<br><br>Well..except with the=
look-ahead part..<br><div style=3D"background-color:rgb(250,250,250);borde=
r-color:rgb(187,187,187);border-style:solid;border-width:1px"><code><div><s=
pan style=3D"color:#008">if</span><span style=3D"color:#660">(enum::</span>=
<span style=3D"color:#000">enumerator </span><span style=3D"color:#660"><=
;</span><span style=3D"color:#000"> enumValue</span><span style=3D"color:#6=
60">)</span></div></code></div>still needs look-ahead to lookup the enum:: =
part.<br></div></blockquote><div><br>Well... yes. That's what's wro=
ng; look-ahead is not something we make compilers do, generally speaking. E=
ven when it means making people write silly things like this:<br><br><div s=
tyle=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 1=
87); border-style: solid; border-width: 1px; overflow-wrap: break-word;" cl=
ass=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subprettyprin=
t"><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> trailing_return</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> a</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> b</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">-></span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">decltype</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">a </span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">+</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> b</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">);</span></div></code></div><br>Whereas `enumValue < enum::=
enumerator` would be able to use the type of the already parsed expression =
`enumValue` as the context to determine the validity of the enumerator.<br>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">A=
nd yes, i am sorry that mixed up the variable and type-stuff. shouldnt happ=
en here. :-|<br><br>But i generally agree with you.<br><br>Btw: the ambigui=
ty would also be resolved if the namespace would not completely deduced. Ju=
st as an alternative:<br>1) for a normal enum the namespace is completely d=
educed. (this also makes the code above clear, since implicit conversion is=
ok)<br>2) for a enum class the namespace is only deduced so far that you s=
till need to write EnumType::ABC.=C2=A0 This is also more along the origina=
l intent.<br>Since the Enum-Name can carry information i would accept that =
too.<br><br>Opinions?<br></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/d603024f-3aac-4a26-9548-2e55685afc6d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d603024f-3aac-4a26-9548-2e55685afc6d=
%40isocpp.org</a>.<br />
------=_Part_4254_2071973091.1495647205264--
------=_Part_4253_1604440355.1495647205264--
.
Author: thealbig@gmail.com
Date: Thu, 25 May 2017 19:29:02 -0700 (PDT)
Raw View
------=_Part_850_825553372.1495765743017
Content-Type: multipart/alternative;
boundary="----=_Part_851_2067098716.1495765743017"
------=_Part_851_2067098716.1495765743017
Content-Type: text/plain; charset="UTF-8"
Sry for the late response,
may i ask what this imlpies for the idea? Is it dead due to such
inconsistencies, or is there any compromise possible?
I mean my wording was actually "Context aware"... in the cases where there
is no clear context its simplty does not work; i wouldnt call it a defect
if a compiler does not know what it cant know.
The proposed idea would still help in a lot of cases i guess.
In the meantime i would like to suggest to look at this maybe on a larger
scale. I mean i explicitly talk about enums here, however if you try to
construct a nested nested class in a namespace in a namespace you begin to
ask for a similar features for constructors and type names.
I mean something like
void CallMe(const Namespace::Class::NestedParent& Parent);
CallMe(Namespace::Class::NestedDerived{InitArgs});
it could be worth investigating if a generalized syntax like
CallMe(auto::NestedDerived{InitArgs});
is possible. Again, i stress that this shall be context aware. In that case
auto:: opens the namespace of the type that is requested at this point. If
no type is known to be requested like in an if, switch or whatever, than
this will not (need to) work.
--
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/1abaf917-51ce-44c1-9f33-e3937d19bc03%40isocpp.org.
------=_Part_851_2067098716.1495765743017
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Sry for the late response,<br>may i ask what this imlpies =
for the idea? Is it dead due to such inconsistencies, or is there any compr=
omise possible?<br>I mean my wording was actually "Context aware"=
.... in the cases where there is no clear context its simplty does not work;=
i wouldnt call it a defect if a compiler does not know what it cant know.<=
br>The proposed idea would still help in a lot of cases i guess.<br><br>In =
the meantime i would like to suggest to look at this maybe on a larger scal=
e. I mean i explicitly talk about enums here, however if you try to constru=
ct a nested nested class in a namespace in a namespace you begin to ask for=
a similar features for constructors and type names.<br><br>I mean somethin=
g like <br>void CallMe(const Namespace::Class::NestedParent& Parent);<b=
r>CallMe(Namespace::Class::NestedDerived{InitArgs});<br><br>it could be wor=
th investigating if a generalized syntax like<br>CallMe(auto::NestedDerived=
{InitArgs});<br>is possible. Again, i stress that this shall be context awa=
re. In that case auto:: opens the namespace of the type that is requested a=
t this point. If no type is known to be requested like in an if, switch or =
whatever, than this will not (need to) work.<br><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/1abaf917-51ce-44c1-9f33-e3937d19bc03%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1abaf917-51ce-44c1-9f33-e3937d19bc03=
%40isocpp.org</a>.<br />
------=_Part_851_2067098716.1495765743017--
------=_Part_850_825553372.1495765743017--
.
Author: Magnus Fromreide <magfr@lysator.liu.se>
Date: Fri, 26 May 2017 07:39:43 +0200
Raw View
On Thu, May 25, 2017 at 07:29:02PM -0700, thealbig@gmail.com wrote:
> Sry for the late response,
> may i ask what this imlpies for the idea? Is it dead due to such
> inconsistencies, or is there any compromise possible?
> I mean my wording was actually "Context aware"... in the cases where there
> is no clear context its simplty does not work; i wouldnt call it a defect
> if a compiler does not know what it cant know.
> The proposed idea would still help in a lot of cases i guess.
>
> In the meantime i would like to suggest to look at this maybe on a larger
> scale. I mean i explicitly talk about enums here, however if you try to
> construct a nested nested class in a namespace in a namespace you begin to
> ask for a similar features for constructors and type names.
>
> I mean something like
> void CallMe(const Namespace::Class::NestedParent& Parent);
> CallMe(Namespace::Class::NestedDerived{InitArgs});
>
> it could be worth investigating if a generalized syntax like
> CallMe(auto::NestedDerived{InitArgs});
> is possible. Again, i stress that this shall be context aware. In that case
> auto:: opens the namespace of the type that is requested at this point. If
> no type is known to be requested like in an if, switch or whatever, than
> this will not (need to) work.
How will this interact with SFINAE uses that are expected to fail, will some
of them stop failing?
/MF
--
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/20170526053943.GA18652%40noemi.
.
Author: thealbig@gmail.com
Date: Fri, 26 May 2017 06:41:30 -0700 (PDT)
Raw View
------=_Part_1151_1454041883.1495806090421
Content-Type: multipart/alternative;
boundary="----=_Part_1152_2058389199.1495806090422"
------=_Part_1152_2058389199.1495806090422
Content-Type: text/plain; charset="UTF-8"
No it will not break code since a syntax like auto::Cass is currently
unavailable and like Nicol proposed the syntax does imply intent to use
automatic namespace lookup, so i dont think there will be unexpected
behavior at any point.
consider
template< typename T, typename = std::enable_if< std::is_convertible<T,
Namespace::Cass:NestedParent*>::value >::type SFINAEFunc(int abc)
In that case the is_convertible provides _NO_ context information which
identifies the namepsace-path to the typename T. so calling
SFINAEFunc<auto::NestedChild*> will not work.
This feature is really intented to be usefull during function calls to keep
the argument list shorter and during assignments to keep the rhs shorter
than the lhs. I do not think that there are not a lot of places where
context awareness works and i guess this will mostly impact enums.
This is real code in my Microcontroller:
Accelerometer.WriteRegister(CLIS3DH::SCtrl_Reg4{.SPI_3WireMode = false,
..SelfTestEn = 0, .HighResolutionMode = 0,
.FullScale =
*CLIS3DH::SCtrl_Reg4::eFullScale::*_2g, .MSBOnLowerAddr = false,
..BlockDataUpdate = true});
Please let me write
Accelerometer.WriteRegister(CLIS3DH::SCtrl_Reg4{.SPI_3WireMode = false,
..SelfTestEn = 0, .HighResolutionMode = 0,
.FullScale = *auto::*_2g,
..MSBOnLowerAddr = false, .BlockDataUpdate = true});
not that i cant write *auto::*SCtrl_Reg4 in that case, because the
WriteRegister function looks like:
template<typename T, typename = std::enable_if<T::Addr>> void
WriteRegister(const T& RegDesc) const
So T can not be decuced from the argument unless its fully named.
Now it would be nice to be able to declare it along the lines of
template<typename T, ..> void WriteRegister(const *CLIS3DH::*T& RegDesc)
const
template<typename *CLIS3DH::*T, ..> void WriteRegister(const T& RegDesc)
const
template<typename namespace *CLIS3DH::*T, ..> void WriteRegister(const T&
RegDesc) const
to only accept types from a certain namespace which then would enable the
*auto::*SCtrl_Reg4 syntax.
--
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/362c332c-e99f-438d-8153-20d7b9451e4b%40isocpp.org.
------=_Part_1152_2058389199.1495806090422
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">No it will not break code since a syntax like auto::Cass i=
s currently unavailable and like Nicol proposed the syntax does imply inten=
t to use automatic namespace lookup, so i dont think there will be unexpect=
ed behavior at any point.<br>consider <br><div style=3D"background-color:rg=
b(250,250,250);border-color:rgb(187,187,187);border-style:solid;border-widt=
h:1px"><code><div>template< typename T, typename =3D std::enable_if<=
=20
std::is_convertible<T, Namespace::Cass:NestedParent*>::value=20
>::type=C2=A0 SFINAEFunc(int abc)<span style=3D"color:#660"></span></div=
></code></div>In that case the is_convertible provides=C2=A0 _NO_ context i=
nformation which identifies the namepsace-path to the typename T.=C2=A0 so =
calling SFINAEFunc<auto::NestedChild*> will not work.<br>This feature=
is really intented to be usefull during function calls to keep the argumen=
t list shorter and during assignments to keep the rhs shorter than the lhs.=
I do not think that there are not a lot of places where context awareness =
works and i guess this will mostly impact enums.<br><br>This is real code i=
n my Microcontroller:<br><div style=3D"background-color:rgb(250,250,250);bo=
rder-color:rgb(187,187,187);border-style:solid;border-width:1px"><code><div=
>Accelerometer.WriteRegister(CLIS3DH::SCtrl_Reg4{.SPI_3WireMode =3D false, =
..SelfTestEn =3D 0, .HighResolutionMode =3D 0,<br>=C2=A0=C2=A0=C2=A0 =C2=A0=
=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=
=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 .FullScale =3D <b>CLIS3=
DH::SCtrl_Reg4::eFullScale::</b>_2g, .MSBOnLowerAddr =3D false, .BlockDataU=
pdate =3D true});<span style=3D"color:#000"></span></div></code></div><br>P=
lease let me write<br><div style=3D"background-color:rgb(250,250,250);borde=
r-color:rgb(187,187,187);border-style:solid;border-width:1px"><code><div>Ac=
celerometer.WriteRegister(CLIS3DH::SCtrl_Reg4{.SPI_3WireMode =3D false, .Se=
lfTestEn =3D 0, .HighResolutionMode =3D 0,<br>=C2=A0=C2=A0=C2=A0 =C2=A0=C2=
=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=
=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 .FullScale =
=3D <b>auto::</b>_2g, .MSBOnLowerAddr =3D false, .BlockDataUpdate =3D true}=
);<br><span style=3D"color:#660"></span></div></code></div>not that i cant =
write <span style=3D"font-family: courier new,monospace;"><b>auto::</b>SCtr=
l_Reg4</span> in that case, because the WriteRegister function looks like:<=
br><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187=
,187);border-style:solid;border-width:1px"><code><div>template<typename =
T, typename =3D std::enable_if<T::Addr>> void WriteRegister(const =
T& RegDesc) const<span style=3D"color:#660"></span></div></code></div>S=
o T can not be decuced from the argument unless its fully named.<br><br>Now=
it would be nice to be able to declare it along the lines of<br><div style=
=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);border-=
style:solid;border-width:1px"><code><div>template<typename T, ..> voi=
d WriteRegister(const <b>CLIS3DH::</b>T& RegDesc) const<br>template<=
typename <b>CLIS3DH::</b>T, ..> void WriteRegister(const T& RegDesc)=
const<br><code>template<typename namespace <b>CLIS3DH::</b>T, ..> vo=
id WriteRegister(const T& RegDesc) const</code><br><span style=3D"color=
:#660"></span></div></code></div>to only accept types from a certain namesp=
ace which then would enable the <b>auto::</b>SCtrl_Reg4 syntax.<br>=C2=A0=
=C2=A0=C2=A0 <br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/362c332c-e99f-438d-8153-20d7b9451e4b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/362c332c-e99f-438d-8153-20d7b9451e4b=
%40isocpp.org</a>.<br />
------=_Part_1152_2058389199.1495806090422--
------=_Part_1151_1454041883.1495806090421--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 26 May 2017 08:09:24 -0700 (PDT)
Raw View
------=_Part_1167_845689765.1495811364346
Content-Type: multipart/alternative;
boundary="----=_Part_1168_737644127.1495811364346"
------=_Part_1168_737644127.1495811364346
Content-Type: text/plain; charset="UTF-8"
On Thursday, May 25, 2017 at 10:29:03 PM UTC-4, thea...@gmail.com wrote:
>
> Sry for the late response,
> may i ask what this imlpies for the idea? Is it dead due to such
> inconsistencies, or is there any compromise possible?
>
That's up to you.
This forum is *not* the C++ standard committee. What we discuss here
doesn't get applied or even considered by the committee simply because we
discuss it. Proposals only get to the committee by actually... being
proposed <https://isocpp.org/std/the-life-of-an-iso-proposal>.
So it's up to you how you want to move forward, if you want to do so at
all. If you want to push forward with it and come up with a formal proposal
that requires look-ahead, don't be surprised if there's resistance in the
actual committee.
I mean my wording was actually "Context aware"... in the cases where there
> is no clear context its simplty does not work; i wouldnt call it a defect
> if a compiler does not know what it cant know.
>
My point was to refute your argument for greater consistency. I don't care
if users have to spell out the full name of an enumerator in some cases.
But you seemed to think that your preferred syntax make the full name
obsolete, so I pointed out cases where it wasn't possible.
> The proposed idea would still help in a lot of cases i guess.
>
> In the meantime i would like to suggest to look at this maybe on a larger
> scale. I mean i explicitly talk about enums here, however if you try to
> construct a nested nested class in a namespace in a namespace you begin to
> ask for a similar features for constructors and type names.
>
> I mean something like
> void CallMe(const Namespace::Class::NestedParent& Parent);
> CallMe(Namespace::Class::NestedDerived{InitArgs});
>
But... you used a braced-init-list. So unless the constructor you were
looking for is `explicit`, you could have just said `CallMe({InitArgs})`.
And if it is explicit, then I want to see the type's name. If that name
happens to be long, that's fine. I need to see the *entire* name so that I
can go track it down. `auto::NestedDerived` tells me absolutely nothing.
I'd much rather fix list initialization so that we could use
braced-init-lists more frequently and correctly than to allow this
`auto::Typename` syntax.
it could be worth investigating if a generalized syntax like
> CallMe(auto::NestedDerived{InitArgs});
> is possible. Again, i stress that this shall be context aware. In that
> case auto:: opens the namespace of the type that is requested at this
> point. If no type is known to be requested like in an if, switch or
> whatever, than this will not (need to) work.
>
--
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/51bdc664-8a0d-47fd-9f9a-5573e50e7494%40isocpp.org.
------=_Part_1168_737644127.1495811364346
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, May 25, 2017 at 10:29:03 PM UTC-4, thea...@gm=
ail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
>Sry for the late response,<br>may i ask what this imlpies for the idea? Is=
it dead due to such inconsistencies, or is there any compromise possible?<=
br></div></blockquote><div><br>That's up to you.<br><br>This forum is <=
i>not</i> the C++ standard committee. What we discuss here doesn't get =
applied or even considered by the committee simply because we discuss it. P=
roposals only get to the committee by actually... <a href=3D"https://isocpp=
..org/std/the-life-of-an-iso-proposal">being proposed</a>.<br><br>So it'=
s up to you how you want to move forward, if you want to do so at all. If y=
ou want to push forward with it and come up with a formal proposal that req=
uires look-ahead, don't be surprised if there's resistance in the a=
ctual committee.<br><br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
<div dir=3D"ltr">I mean my wording was actually "Context aware"..=
.. in the cases where there is no clear context its simplty does not work; i=
wouldnt call it a defect if a compiler does not know what it cant know.<br=
></div></blockquote><div><br>My point was to refute your argument for great=
er consistency. I don't care if users have to spell out the full name o=
f an enumerator in some cases. But you seemed to think that your preferred =
syntax make the full name obsolete, so I pointed out cases where it wasn=
9;t possible.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr">The proposed idea would still help in a lot of cases i gues=
s.<br><br>In the meantime i would like to suggest to look at this maybe on =
a larger scale. I mean i explicitly talk about enums here, however if you t=
ry to construct a nested nested class in a namespace in a namespace you beg=
in to ask for a similar features for constructors and type names.<br><br>I =
mean something like <br>void CallMe(const Namespace::Class::<wbr>NestedPare=
nt& Parent);<br>CallMe(Namespace::Class::<wbr>NestedDerived{InitArgs});=
<br></div></blockquote><div><br>But... you used a braced-init-list. So unle=
ss the constructor you were looking for is `explicit`, you could have just =
said `CallMe({InitArgs})`. And if it is explicit, then I want to see the ty=
pe's name. If that name happens to be long, that's fine. I need to =
see the <i>entire</i> name so that I can go track it down. `auto::NestedDer=
ived` tells me absolutely nothing.<br><br>I'd much rather fix list init=
ialization so that we could use braced-init-lists more frequently and corre=
ctly than to allow this `auto::Typename` syntax.<br><br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
#ccc solid;padding-left: 1ex;"><div dir=3D"ltr">it could be worth investig=
ating if a generalized syntax like<br>CallMe(auto::NestedDerived{<wbr>InitA=
rgs});<br>is possible. Again, i stress that this shall be context aware. In=
that case auto:: opens the namespace of the type that is requested at this=
point. If no type is known to be requested like in an if, switch or whatev=
er, than this will not (need to) work.<br></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/51bdc664-8a0d-47fd-9f9a-5573e50e7494%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/51bdc664-8a0d-47fd-9f9a-5573e50e7494=
%40isocpp.org</a>.<br />
------=_Part_1168_737644127.1495811364346--
------=_Part_1167_845689765.1495811364346--
.
Author: thealbig@gmail.com
Date: Fri, 26 May 2017 09:54:02 -0700 (PDT)
Raw View
------=_Part_1207_1392707707.1495817642652
Content-Type: multipart/alternative;
boundary="----=_Part_1208_2044701365.1495817642653"
------=_Part_1208_2044701365.1495817642653
Content-Type: text/plain; charset="UTF-8"
Yes yes, this place is still a place where one can discuss if an idea is
stupid or not :-)
I am sorry with the braced initializer, i didnt realize that if a
parent-class is expected the braced initialisation of a child class can
happen without telling which type of child it actually is. I should check
my examples before writing them from the top of my head.I'd much rather fix
list initialization so that we could use braced-init-lists more frequently
and correctly than to allow this `auto::Typename` syntax.
> it could be worth investigating if a generalized syntax like
>> CallMe(auto::NestedDerived{InitArgs});
>> is possible. Again, i stress that this shall be context aware. In that
>> case auto:: opens the namespace of the type that is requested at this
>> point. If no type is known to be requested like in an if, switch or
>> whatever, than this will not (need to) work.
>>
>
See this is what i would like to hear. I dont want to bother people with
stuff where other things are more important than my type name complexity.
I also see that the crowd issnt cheering for this idea and maybe i just
have a weird programming style so others do not have the same issues. :-)
--
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/62a6c6e5-058b-4d1e-90c0-ab9e843b658f%40isocpp.org.
------=_Part_1208_2044701365.1495817642653
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Yes yes, this place is still a place where one can discuss=
if an idea is stupid or not :-)<br>I am sorry with the braced initializer,=
i didnt realize that if a parent-class is expected the braced initialisati=
on of a child class can happen without telling which type of child it actua=
lly is. I should check my examples before writing them from the top of my h=
ead.I'd much rather fix list initialization so that we could use braced=
-init-lists more frequently and correctly than to allow this `auto::Typenam=
e` syntax.<br><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div dir=3D"ltr"><div></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr">it could be worth investigating if a generalized syntax like<br>=
CallMe(auto::NestedDerived{<wbr>InitArgs});<br>is possible. Again, i stress=
that this shall be context aware. In that case auto:: opens the namespace =
of the type that is requested at this point. If no type is known to be requ=
ested like in an if, switch or whatever, than this will not (need to) work.=
<br></div></blockquote></div></blockquote><div><br>See this is what i would=
like to hear. I dont want to bother people with stuff where other things a=
re more important than my type name complexity. <br>I also see that the cro=
wd issnt cheering for this idea and maybe i just have a weird programming s=
tyle so others do not have the same issues. :-)<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/62a6c6e5-058b-4d1e-90c0-ab9e843b658f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/62a6c6e5-058b-4d1e-90c0-ab9e843b658f=
%40isocpp.org</a>.<br />
------=_Part_1208_2044701365.1495817642653--
------=_Part_1207_1392707707.1495817642652--
.