------=_Part_1051_170835979.1536949952740
Content-Type: multipart/alternative;
 boundary="----=_Part_1052_1584255857.1536949952740"

------=_Part_1052_1584255857.1536949952740
Content-Type: text/plain; charset="UTF-8"

I have considering how to better encode class definitions.

I started out writing a class and created a large set of "getters" and
"setters" for the different
attributes that make up the class.

Then I discovered the unscoped enum type.  This was fine when only 1 are 2
types were
needed and I did not consider the other objects that may be within the same
global name space.

Then I discovered scoped enum types (enum class).  This was better.
Then trying to use this in an object with many different enum definitions
complicated things.

I assumed that by naming an element with an enum class, it would limit the
values in assign
statements to those values.  However, the current implementation requires
me to also include
the ename class name to the value being assigned.  This seems redundant.

for instance

 enum class att1 { a, b, c};
 att1 x = att1:a;

This is not so bad within the code that I write.

The problem really comes when yo want to allow other programmers to use
your code,
and you want to include an enum class variable as a function argument.

for example:

    enum class optns { setup, process, post, acknowledge, stop, ... );

    void  Myclass::include( optns  op) {....};

   Myclass  ex;

    Now the user has code  "

    ex::include(optns::setup);

   Why have the user remember the name of the class as well as the function?

   Why would this not be acceptable:

   ex::include(setup);

  and in my code why could I not code:

   optns selected_value = post;

   The use of the class option prevents the polluting of the
   global name  space, but then the current implementation ignores the
   fact and requires you to name the enum class name in referencing
   the value to be set.

   The alternative is to write an individual setter function for each
enumerator
   value e.g.:       include_setp(), include_process(), etc..

   The use of #defines and unscoped enums are even worse options.

    I realize that enumerator values can be used outside of enum named
    types. In that case requiring the class name seems necessary.

--
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/2d514d01-b865-4d59-8cb2-f9094e818db6%40isocpp.org.

------=_Part_1052_1584255857.1536949952740
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I have considering how to better encode class definitions.=
=C2=A0<div><br></div><div>I started out writing a class and created a large=
 set of &quot;getters&quot; and &quot;setters&quot; for the different</div>=
<div>attributes that make up the class.=C2=A0</div><div><br></div><div>Then=
 I discovered the unscoped enum type.=C2=A0 This was fine when only 1 are 2=
 types were</div><div>needed and I did not consider the other objects that =
may be within the same global name space.=C2=A0</div><div><br></div><div>Th=
en I discovered scoped enum types (enum class).=C2=A0 This was better.=C2=
=A0</div><div>Then trying to use this in an object with many different enum=
 definitions complicated things.</div><div><br></div><div>I assumed that by=
 naming an element with an enum class, it would limit the values in assign<=
/div><div>statements to those values.=C2=A0 However, the current implementa=
tion requires me to also include</div><div>the ename class name to the valu=
e being assigned.=C2=A0 This seems redundant.=C2=A0=C2=A0</div><div><br></d=
iv><div>for instance=C2=A0 =C2=A0=C2=A0</div><div><br></div><div>=C2=A0enum=
 class att1 { a, b, c};</div><div>=C2=A0att1 x =3D att1:a;</div><div><br></=
div><div>This is not so bad within the code that I write.=C2=A0</div><div><=
br></div><div>The problem really comes when yo want to allow other programm=
ers to use your code,=C2=A0</div><div>and you want to include an enum class=
 variable as a function argument.=C2=A0</div><div><br></div><div>for exampl=
e:</div><div><br></div><div>=C2=A0 =C2=A0 enum class optns { setup, process=
, post, acknowledge, stop, ... );</div><div><br></div><div>=C2=A0 =C2=A0 vo=
id=C2=A0 Myclass::include( optns=C2=A0 op) {....};</div><div><br></div><div=
>=C2=A0 =C2=A0Myclass=C2=A0 ex;</div><div><br></div><div>=C2=A0 =C2=A0 Now =
the user has code=C2=A0 &quot;=C2=A0</div><div><br></div><div>=C2=A0 =C2=A0=
 ex::include(optns::setup);=C2=A0</div><div><br></div><div>=C2=A0 =C2=A0Why=
 have the user remember the name of the class as well as the function?</div=
><div><br></div><div>=C2=A0 =C2=A0Why would this not be acceptable:</div><d=
iv><br></div><div>=C2=A0 =C2=A0ex::include(setup);</div><div><br></div><div=
>=C2=A0 and in my code why could I not code:</div><div><br></div><div>=C2=
=A0 =C2=A0optns selected_value =3D post;</div><div><br></div><div>=C2=A0 =
=C2=A0The use of the class option prevents the polluting of the</div><div>=
=C2=A0 =C2=A0global name=C2=A0 space, but then the current implementation i=
gnores the</div><div>=C2=A0 =C2=A0fact and requires you to name the enum cl=
ass name in referencing=C2=A0</div><div>=C2=A0 =C2=A0the value to be set.=
=C2=A0=C2=A0</div><div><br></div><div>=C2=A0 =C2=A0The alternative is to wr=
ite an individual setter function for each enumerator=C2=A0</div><div>=C2=
=A0 =C2=A0value e.g.:=C2=A0 =C2=A0 =C2=A0 =C2=A0include_setp(), include_pro=
cess(), etc..=C2=A0</div><div>=C2=A0 =C2=A0</div><div>=C2=A0 =C2=A0The use =
of #defines and unscoped enums are even worse options.=C2=A0</div><div>=C2=
=A0=C2=A0</div><div>=C2=A0 =C2=A0 I realize that enumerator values can be u=
sed outside of enum named=C2=A0</div><div>=C2=A0 =C2=A0 types. In that case=
 requiring the class name seems necessary.=C2=A0</div><div><br></div></div>

<p></p>

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

------=_Part_1052_1584255857.1536949952740--

------=_Part_1051_170835979.1536949952740--

.

On 2018-09-14 14:32, Lawrence Emke wrote:
> [...]
>     Now the user has code  "
>
>     ex::include(optns::setup);
>
>    Why have the user remember the name of the class as well as the function?
>
>    Why would this not be acceptable:
>
>    ex::include(setup);

You're not the first person to ask, though I'm not sure if any of the
previous muttering has resulted in a formal proposal or not.

One of the problems with this idea, however, is that it puts the cart
before the horse as far as overload resolution. You propose that the
compiler should look at the call to `include` and use that information
to do look-up of `setup`. But what overload of `include` is being
called? Because `setup` is not a name in the current scope, the compiler
doesn't know what type it has, so it doesn't know how to do overload
lookup on `include`.

Sure, this can be made to work in "easy" cases, but what about:

  enum class foo { TRICKY };
  enum class bar { TRICKY };

  void func(foo); // #1
  void func(bar); // #2

  func(TRICKY);

Does the above call #1, #2, or neither?

Almost certainly it would have to be ill-formed, but these sorts of
questions would need to be answered. If you can spell out how the
compiler is supposed to resolve what `setup` means, in a way that deals
with corner cases like the above, that would be an important step toward
seeing such a feature accepted. Something else that would really help is
actually implementing it in clang.

--
Matthew

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/13d5e364-4a16-967c-0574-ceeba3c7f002%40gmail.com.

.

--00000000000093586a0575d96b46
Content-Type: text/plain; charset="UTF-8"

>
> I assumed that by naming an element with an enum class, it would limit the
> values in assign
> statements to those values.  However, the current implementation requires
> me to also include
> the ename class name to the value being assigned.  This seems redundant.
>

Ada handled this brilliantly decades ago.  It comes as a confluence of a
pair of Ada
language features interacting with synergy:

1) Ada overloading includes return types.  That is, in C++ terms, you can
have

    int f();         // #1
    double f();      // #2
    int a = f();     // Calls #1
    double d = f();  // Calls #2

2) A function with no parameters is called without parentheses.  So the
above would
look more like this (again, C++ style, not actual Ada):

    int a = f;      // Calls (not converts) #1
    double d = f;   // Calls (not converts) #2

3) Here comes the brilliant synergy:  enumeration literals are considered
to be zero-parameter
functions that return the literal value.  So when you have two enumerations
that both have a
literal with the same spelling, they are "really" functions that return
values of their respective
enumeration types, they're invoked without parentheses, and overloading
picks the correct one
from context!

You get the equivalent of the following:

    enum Color { lime, orange };
    enum Fruit { orange, lime };
    Color c = orange;  // "Calls" Color::orange()
    Fruit f = lime;    // "Calls" Fruit::lime()

(Of course, no actual function calls happen in the compiled code.)

--
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/CAHSYqdavmSwzZvGzpg2uTTsEi48mLPhtLGwMsjFgQqz%2B_Yshqw%40mail.gmail.com.

--00000000000093586a0575d96b46
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<div dir=3D"ltr"><div>I assumed that by naming an element with an enum clas=
s, it would limit the values in assign<br></div><div>statements to those va=
lues.=C2=A0 However, the current implementation requires me to also include=
</div><div>the ename class name to the value being assigned.=C2=A0 This see=
ms redundant.</div></div></blockquote><div><br>Ada handled this brilliantly=
 decades ago.=C2=A0 It comes as a confluence of a pair of Ada<br>language f=
eatures interacting with synergy:<br><br>1) Ada overloading includes return=
 types.=C2=A0 That is, in C++ terms, you can have<br><br><font face=3D"mono=
space, monospace">=C2=A0 =C2=A0 int f();=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/=
/ #1<br>=C2=A0 =C2=A0 double f();=C2=A0 =C2=A0 =C2=A0 // #2<br>=C2=A0 =C2=
=A0 int a =3D f();=C2=A0 =C2=A0 =C2=A0// Calls #1<br>=C2=A0 =C2=A0 double d=
 =3D f();=C2=A0 // Calls #2<br></font><br>2) A function with no parameters =
is called without parentheses.=C2=A0 So the above would<br>look more like t=
his (again, C++ style, not actual Ada):<br><br><font face=3D"monospace, mon=
ospace">=C2=A0 =C2=A0 int a =3D f;=C2=A0 =C2=A0 =C2=A0 // Calls (not conver=
ts) #1<br>=C2=A0 =C2=A0 double d =3D f;=C2=A0 =C2=A0// Calls (not converts)=
 #2<br></font><br>3) Here comes the brilliant synergy:=C2=A0 enumeration li=
terals are considered to be zero-parameter<br>functions that return the lit=
eral value.=C2=A0 So when you have two enumerations that both have a<br>lit=
eral with the same spelling, they are &quot;really&quot; functions that ret=
urn values of their respective<br>enumeration types, they&#39;re invoked wi=
thout parentheses, and overloading picks the correct one<br>from context!</=
div><div><br>You get the equivalent of the following:<br><br><font face=3D"=
monospace, monospace">=C2=A0 =C2=A0 enum Color { lime, orange };</font><br>=
<font face=3D"monospace, monospace">=C2=A0 =C2=A0 enum Fruit { orange, lime=
 };</font><br><font face=3D"monospace, monospace">=C2=A0 =C2=A0 Color c =3D=
 orange;=C2=A0 // &quot;Calls&quot; Color::orange()</font><br><font face=3D=
"monospace, monospace">=C2=A0 =C2=A0 Fruit f =3D lime;=C2=A0 =C2=A0 // &quo=
t;Calls&quot; Fruit::lime()</font><br><font face=3D"arial, helvetica, sans-=
serif"><br>(Of course, no actual function calls happen in the compiled code=
..)</font></div></div></div>

<p></p>

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

--00000000000093586a0575d96b46--

.

--00000000000090589d0575d976bf
Content-Type: text/plain; charset="UTF-8"

On Fri, Sep 14, 2018 at 2:58 PM Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> Sure, this can be made to work in "easy" cases, but what about:
>
>   enum class foo { TRICKY };
>   enum class bar { TRICKY };
>
>   void func(foo); // #1
>   void func(bar); // #2
>
>   func(TRICKY);
>
> Does the above call #1, #2, or neither?
>

In Ada, this would be a compilation error, since overloading (including
return types) fails
to resolve to a single interpretation.  If only one of the functions were
visible, it would be
called with correct enumeration value.

--
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/CAHSYqdaDcd_V-%3DFWtCPUm8NQmSfV%3DHTWB007ZRv3%3DwcGnFVuVA%40mail.gmail.com.

--00000000000090589d0575d976bf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, Sep 14=
, 2018 at 2:58 PM Matthew Woehlke &lt;<a href=3D"mailto:mwoehlke.floss@gmai=
l.com">mwoehlke.floss@gmail.com</a>&gt; wrote:</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">
Sure, this can be made to work in &quot;easy&quot; cases, but what about:<b=
r>
<br>
=C2=A0 enum class foo { TRICKY };<br>
=C2=A0 enum class bar { TRICKY };<br>
<br>
=C2=A0 void func(foo); // #1<br>
=C2=A0 void func(bar); // #2<br>
<br>
=C2=A0 func(TRICKY);<br>
<br>
Does the above call #1, #2, or neither?<br></blockquote><div><br>In Ada, th=
is would be a compilation error, since overloading (including return types)=
 fails<br>to resolve to a single interpretation.=C2=A0 If only one of the f=
unctions were visible, it would be<br>called with correct enumeration value=
..=C2=A0</div></div></div>

<p></p>

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

--00000000000090589d0575d976bf--

.

--0000000000004fc51d0575db5ae4
Content-Type: text/plain; charset="UTF-8"

In the case:

enum class foo { TRICKY };
  enum class bar { TRICKY };

  void func(foo); // #1
  void func(bar); // #2

I see your point.

In this case you will have to require the enum class name.
Can the compiler detect this situation where confusion can occur?
Can the compiler raise a warning to force you to specify the class in this
situation?

if there is a function overload syntax situation in which enums are used,
can it possibly lead to
possible confusion because the enums have one or more common enumerators,
then
raise an error condition.

As in all programming, if it is probabile (p>0) of an event is possible,
then it will happen, no matter how small the probability.  I understand
this is exception coding, and designers dislike any exception processing.

I don't see that "assignment" has this edge case.  I don't see the edge
case  in a "switch" statement.

The question is who is the audience for the compiler? We can make things
easy for
the designers or easy for the users (programmers). Who is serving who?  Is
the edge case too important, too prevalent, too complicated to avoid the
exception code to flag the situation, and
choose the simplest solution of requiring the class name for every enum
class for every
enumerator reference.

I went the road of having 3 non-argument functions for each bool attribute
in a class.
With 12 attributes there would be 36 individual functions, Using enums
there could be 3 functions.

I don't talk like server.include(machine_option::setup).  I think in terms
of "server.include(setup)".
My thoughts are limited to then environment in which I am working.  To have
to go outside of
that and qualify what should be obvious, is a distractions.  Maybe it is
not so bad. It will make
programmers all that more valuable. Or cost more time trying to get
everything exactly correct,
because there might be an edge case where it is not clear what is ment.

What if I wanted to create "machine_option i386[] = ( setup, ....);" and
pass the array to the include
function?  (aside: This technique is not possible with 36 individual
functions. 36 #define statements is not good).  Why do I have to include
the enum class name in each array member?  How do I pass this array to a
function  "server.include( machine_option::i386)"?   It seems a bit
redundant.

I currently have an object that uses 6 enums) each  has a number of
enumerators runs for 3 to 12. How many individual functions would I need?).
And why must my users remember which enum class with each enumerator. that
goes to which function, and include its long name in addition to the value
in the function call. Will the misspelled enum class name-enumerator syntax
cause more problems than the use of a common word like "setup"?  Studies
have found the longer the word the greater the occurrence of misspelling
it.  Should I name my enums "a", "b", "c", "d", "e", "f" ?

My thought is that there has to be a better way.


On Fri, Sep 14, 2018 at 2:02 PM Hyman Rosen <hyman.rosen@gmail.com> wrote:

> On Fri, Sep 14, 2018 at 2:58 PM Matthew Woehlke <mwoehlke.floss@gmail.com>
> wrote:
>
>> Sure, this can be made to work in "easy" cases, but what about:
>>
>>   enum class foo { TRICKY };
>>   enum class bar { TRICKY };
>>
>>   void func(foo); // #1
>>   void func(bar); // #2
>>
>>   func(TRICKY);
>>
>> Does the above call #1, #2, or neither?
>>
>
> In Ada, this would be a compilation error, since overloading (including
> return types) fails
> to resolve to a single interpretation.  If only one of the functions were
> visible, it would be
> called with correct enumeration value.
>
> --
> 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/CAHSYqdaDcd_V-%3DFWtCPUm8NQmSfV%3DHTWB007ZRv3%3DwcGnFVuVA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdaDcd_V-%3DFWtCPUm8NQmSfV%3DHTWB007ZRv3%3DwcGnFVuVA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BAqvO3ks9zPzmFbkkw84o%2BcxSuw9SRcCaSd%3DjN5nVoK5mU01Q%40mail.gmail.com.

--0000000000004fc51d0575db5ae4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">In the case:<div><br></div><div><span style=3D"color:rgb(8=
0,0,80)">enum class foo { TRICKY };</span><br style=3D"color:rgb(80,0,80)">=
<span style=3D"color:rgb(80,0,80)">=C2=A0 enum class bar { TRICKY };</span>=
<br style=3D"color:rgb(80,0,80)"><br style=3D"color:rgb(80,0,80)"><span sty=
le=3D"color:rgb(80,0,80)">=C2=A0 void func(foo); // #1</span><br style=3D"c=
olor:rgb(80,0,80)"><span style=3D"color:rgb(80,0,80)">=C2=A0 void func(bar)=
; // #2</span><br style=3D"color:rgb(80,0,80)"></div><div><br></div><div>I =
see your point.=C2=A0</div><div><br></div><div>In this case you will have t=
o require the enum class name.=C2=A0</div><div>Can the compiler detect this=
 situation where confusion can occur?=C2=A0</div><div>Can the compiler rais=
e a warning to force you to specify the class in this situation?=C2=A0</div=
><div><br></div><div>if there is a function overload syntax situation in wh=
ich enums are used, can it possibly lead to</div><div>possible confusion be=
cause the enums have one or more common enumerators, then</div><div>raise a=
n error condition.=C2=A0=C2=A0</div><div><br></div><div>As in all programmi=
ng, if it is probabile (p&gt;0) of an event is possible, then it will happe=
n, no matter how small the probability.=C2=A0 I understand this is exceptio=
n coding, and designers dislike any exception processing.=C2=A0=C2=A0</div>=
<div><br></div><div>I don&#39;t see that &quot;assignment&quot; has this ed=
ge case.=C2=A0 I don&#39;t see the edge case=C2=A0 in a &quot;switch&quot; =
statement.</div><div><br></div><div>The question is who is the audience for=
 the compiler? We can make things easy for</div><div>the designers or easy =
for the users (programmers). Who is serving who?=C2=A0 Is the edge case too=
 important, too prevalent, too complicated to avoid the exception code to f=
lag the situation, and</div><div>choose the simplest solution of requiring =
the class name for every enum class for every</div><div>enumerator referenc=
e.=C2=A0=C2=A0</div><div><br></div><div>I went the road of having 3 non-arg=
ument functions for each bool attribute in a class.=C2=A0</div><div>With 12=
 attributes there would be 36 individual functions, Using enums there could=
 be 3 functions.</div><div><br></div><div>I don&#39;t talk like server.incl=
ude(machine_option::setup).=C2=A0 I think in terms of &quot;server.include(=
setup)&quot;.</div><div>My thoughts are limited to then environment in whic=
h I am working.=C2=A0 To have to go outside of</div><div>that and qualify w=
hat should be obvious, is a distractions.=C2=A0 Maybe it is not so bad. It =
will make</div><div>programmers all that more valuable. Or cost more time t=
rying to get everything exactly correct,</div><div>because there might be a=
n edge case where it is not clear what is ment.=C2=A0</div><div><br></div><=
div>What if I wanted to create &quot;machine_option i386[] =3D ( setup, ...=
..);&quot; and pass the array to the include</div><div>function?=C2=A0 (asid=
e: This technique is not possible with 36 individual functions. 36 #define =
statements is not good).=C2=A0 Why do I have to include the enum class name=
 in each array member?=C2=A0 How do I pass this array to a function=C2=A0 &=
quot;server.include( machine_option::i386)&quot;?=C2=A0 =C2=A0It seems a bi=
t redundant.=C2=A0 =C2=A0</div><div><br></div><div>I currently have an obje=
ct that uses 6 enums) each=C2=A0 has a number of enumerators runs for 3 to =
12. How many individual functions would I need?). And why must my users rem=
ember which enum class with each enumerator. that goes to which function, a=
nd include its long name in addition to the value in the function call. Wil=
l the misspelled enum class name-enumerator syntax cause more problems than=
 the use of a common word like &quot;setup&quot;?=C2=A0 Studies have found =
the longer the word the greater the occurrence of misspelling it.=C2=A0 Sho=
uld I name my enums &quot;a&quot;, &quot;b&quot;, &quot;c&quot;, &quot;d&qu=
ot;, &quot;e&quot;, &quot;f&quot; ?=C2=A0</div><div>=C2=A0</div><div>My tho=
ught is that there has to be a better way.=C2=A0=C2=A0</div><div><br></div>=
</div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, Sep 14, 2018 =
at 2:02 PM Hyman Rosen &lt;<a href=3D"mailto:hyman.rosen@gmail.com">hyman.r=
osen@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, Sep 14, 201=
8 at 2:58 PM Matthew Woehlke &lt;<a href=3D"mailto:mwoehlke.floss@gmail.com=
" target=3D"_blank">mwoehlke.floss@gmail.com</a>&gt; wrote:</div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">
Sure, this can be made to work in &quot;easy&quot; cases, but what about:<b=
r>
<br>
=C2=A0 enum class foo { TRICKY };<br>
=C2=A0 enum class bar { TRICKY };<br>
<br>
=C2=A0 void func(foo); // #1<br>
=C2=A0 void func(bar); // #2<br>
<br>
=C2=A0 func(TRICKY);<br>
<br>
Does the above call #1, #2, or neither?<br></blockquote><div><br>In Ada, th=
is would be a compilation error, since overloading (including return types)=
 fails<br>to resolve to a single interpretation.=C2=A0 If only one of the f=
unctions were visible, it would be<br>called with correct enumeration value=
..=C2=A0</div></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">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/CAHSYqdaDcd_V-%3DFWtCPUm8NQmSfV%3DHTW=
B007ZRv3%3DwcGnFVuVA%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Df=
ooter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std=
-proposals/CAHSYqdaDcd_V-%3DFWtCPUm8NQmSfV%3DHTWB007ZRv3%3DwcGnFVuVA%40mail=
..gmail.com</a>.<br>
</blockquote></div>

<p></p>

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

--0000000000004fc51d0575db5ae4--

.

------=_Part_1236_771853165.1537013629885
Content-Type: multipart/alternative;
 boundary="----=_Part_1237_1327438137.1537013629885"

------=_Part_1237_1327438137.1537013629885
Content-Type: text/plain; charset="UTF-8"

Note that this will make the code ever so slightly less type safe.

enum class Abort { all };
enum class Launch { all };

void shuttle(Abort);
void rocket(Launch);

// user

shuttle(all);

Now if the user refactors rocket to shuttle, the code will silently change
behavior. We introduce a problem even C does not have.

Also note, this will be a compiler trick which will fail to work with
forwarding and packing arguments into tuple.


Having said that, there is proposal
<http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p1099r0.html> to
allow using an enum as it is a namespace, making the value(s) available
with no qualification for the current scope.


On Saturday, September 15, 2018 at 12:17:39 AM UTC+3, Lawrence Emke wrote:

> In the case:
>
> enum class foo { TRICKY };
>   enum class bar { TRICKY };
>
>   void func(foo); // #1
>   void func(bar); // #2
>
> I see your point.
>
> In this case you will have to require the enum class name.
> Can the compiler detect this situation where confusion can occur?
> Can the compiler raise a warning to force you to specify the class in this
> situation?
>
> if there is a function overload syntax situation in which enums are used,
> can it possibly lead to
> possible confusion because the enums have one or more common enumerators,
> then
> raise an error condition.
>
> As in all programming, if it is probabile (p>0) of an event is possible,
> then it will happen, no matter how small the probability.  I understand
> this is exception coding, and designers dislike any exception processing.
>
> I don't see that "assignment" has this edge case.  I don't see the edge
> case  in a "switch" statement.
>
> The question is who is the audience for the compiler? We can make things
> easy for
> the designers or easy for the users (programmers). Who is serving who?  Is
> the edge case too important, too prevalent, too complicated to avoid the
> exception code to flag the situation, and
> choose the simplest solution of requiring the class name for every enum
> class for every
> enumerator reference.
>
> I went the road of having 3 non-argument functions for each bool attribute
> in a class.
> With 12 attributes there would be 36 individual functions, Using enums
> there could be 3 functions.
>
> I don't talk like server.include(machine_option::setup).  I think in terms
> of "server.include(setup)".
> My thoughts are limited to then environment in which I am working.  To
> have to go outside of
> that and qualify what should be obvious, is a distractions.  Maybe it is
> not so bad. It will make
> programmers all that more valuable. Or cost more time trying to get
> everything exactly correct,
> because there might be an edge case where it is not clear what is ment.
>
> What if I wanted to create "machine_option i386[] = ( setup, ....);" and
> pass the array to the include
> function?  (aside: This technique is not possible with 36 individual
> functions. 36 #define statements is not good).  Why do I have to include
> the enum class name in each array member?  How do I pass this array to a
> function  "server.include( machine_option::i386)"?   It seems a bit
> redundant.
>
> I currently have an object that uses 6 enums) each  has a number of
> enumerators runs for 3 to 12. How many individual functions would I need?).
> And why must my users remember which enum class with each enumerator. that
> goes to which function, and include its long name in addition to the value
> in the function call. Will the misspelled enum class name-enumerator syntax
> cause more problems than the use of a common word like "setup"?  Studies
> have found the longer the word the greater the occurrence of misspelling
> it.  Should I name my enums "a", "b", "c", "d", "e", "f" ?
>
> My thought is that there has to be a better way.
>
>
> On Fri, Sep 14, 2018 at 2:02 PM Hyman Rosen <hyman...@gmail.com
> <javascript:>> wrote:
>
>> On Fri, Sep 14, 2018 at 2:58 PM Matthew Woehlke <mwoehlk...@gmail.com
>> <javascript:>> wrote:
>>
>>> Sure, this can be made to work in "easy" cases, but what about:
>>>
>>>   enum class foo { TRICKY };
>>>   enum class bar { TRICKY };
>>>
>>>   void func(foo); // #1
>>>   void func(bar); // #2
>>>
>>>   func(TRICKY);
>>>
>>> Does the above call #1, #2, or neither?
>>>
>>
>> In Ada, this would be a compilation error, since overloading (including
>> return types) fails
>> to resolve to a single interpretation.  If only one of the functions were
>> visible, it would be
>> called with correct enumeration value.
>>
>> --
>> 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-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdaDcd_V-%3DFWtCPUm8NQmSfV%3DHTWB007ZRv3%3DwcGnFVuVA%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdaDcd_V-%3DFWtCPUm8NQmSfV%3DHTWB007ZRv3%3DwcGnFVuVA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/86bc9b0e-44fd-46fc-b6e3-349af0f9cc8e%40isocpp.org.

------=_Part_1237_1327438137.1537013629885
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Note that this will make the code ever so slightly le=
ss type safe.</div><div><br></div><div><font face=3D"courier new,monospace"=
>enum class Abort { all };<br>enum class Launch { all };</font></div><div><=
font face=3D"courier new,monospace"></font><br></div><div><font face=3D"cou=
rier new,monospace">void shuttle(Abort);<br>void rocket(Launch);=C2=A0</fon=
t></div><div><font face=3D"courier new,monospace"></font><br></div><div><fo=
nt face=3D"courier new,monospace">// user</font></div><div><font face=3D"co=
urier new,monospace"></font><br></div><div><font face=3D"courier new,monosp=
ace"><span style=3D"display: inline !important; float: none; background-col=
or: transparent; color: rgb(34, 34, 34); font-family: courier new,monospace=
; font-size: 13px; font-style: normal; font-variant: normal; font-weight: 4=
00; letter-spacing: normal; orphans: 2; text-align: left; text-decoration: =
none; text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0p=
x; white-space: normal; word-spacing: 0px;">shuttle</span>(all);</font></di=
v><div><font face=3D"courier new,monospace"></font><b></b><i></i><u></u><su=
b></sub><sup></sup><strike></strike><font face=3D"courier new,monospace"></=
font><br></div><div>Now if the user refactors rocket to shuttle, the code w=
ill silently change behavior. We introduce a problem even C does not have.<=
/div><div><br></div><div>Also note, this will be a compiler trick which wil=
l fail to work with forwarding and packing arguments into tuple.</div><div>=
<br></div><div><br></div><div>Having said that, <a href=3D"http://www.open-=
std.org/JTC1/SC22/WG21/docs/papers/2018/p1099r0.html">there is proposal</a>=
 to allow <font face=3D"courier new,monospace">using</font><font face=3D"ar=
ial,sans-serif"> an enum as it is a namespace, making the value(s) availabl=
e with no qualification for the current scope.=C2=A0</font></div><div><font=
 face=3D"courier new,monospace"></font><font face=3D"arial,sans-serif"></fo=
nt><br></div><div><br></div><div>On Saturday, September 15, 2018 at 12:17:3=
9 AM UTC+3, Lawrence Emke wrote:</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div dir=3D"ltr">In the case:<div><br></div><div><span style=3D"col=
or:rgb(80,0,80)">enum class foo { TRICKY };</span><br style=3D"color:rgb(80=
,0,80)"><span style=3D"color:rgb(80,0,80)">=C2=A0 enum class bar { TRICKY }=
;</span><br style=3D"color:rgb(80,0,80)"><br style=3D"color:rgb(80,0,80)"><=
span style=3D"color:rgb(80,0,80)">=C2=A0 void func(foo); // #1</span><br st=
yle=3D"color:rgb(80,0,80)"><span style=3D"color:rgb(80,0,80)">=C2=A0 void f=
unc(bar); // #2</span><br style=3D"color:rgb(80,0,80)"></div><div><br></div=
><div>I see your point.=C2=A0</div><div><br></div><div>In this case you wil=
l have to require the enum class name.=C2=A0</div><div>Can the compiler det=
ect this situation where confusion can occur?=C2=A0</div><div>Can the compi=
ler raise a warning to force you to specify the class in this situation?=C2=
=A0</div><div><br></div><div>if there is a function overload syntax situati=
on in which enums are used, can it possibly lead to</div><div>possible conf=
usion because the enums have one or more common enumerators, then</div><div=
>raise an error condition.=C2=A0=C2=A0</div><div><br></div><div>As in all p=
rogramming, if it is probabile (p&gt;0) of an event is possible, then it wi=
ll happen, no matter how small the probability.=C2=A0 I understand this is =
exception coding, and designers dislike any exception processing.=C2=A0=C2=
=A0</div><div><br></div><div>I don&#39;t see that &quot;assignment&quot; ha=
s this edge case.=C2=A0 I don&#39;t see the edge case=C2=A0 in a &quot;swit=
ch&quot; statement.</div><div><br></div><div>The question is who is the aud=
ience for the compiler? We can make things easy for</div><div>the designers=
 or easy for the users (programmers). Who is serving who?=C2=A0 Is the edge=
 case too important, too prevalent, too complicated to avoid the exception =
code to flag the situation, and</div><div>choose the simplest solution of r=
equiring the class name for every enum class for every</div><div>enumerator=
 reference.=C2=A0=C2=A0</div><div><br></div><div>I went the road of having =
3 non-argument functions for each bool attribute in a class.=C2=A0</div><di=
v>With 12 attributes there would be 36 individual functions, Using enums th=
ere could be 3 functions.</div><div><br></div><div>I don&#39;t talk like se=
rver.include(machine_option:<wbr>:setup).=C2=A0 I think in terms of &quot;s=
erver.include(setup)&quot;.</div><div>My thoughts are limited to then envir=
onment in which I am working.=C2=A0 To have to go outside of</div><div>that=
 and qualify what should be obvious, is a distractions.=C2=A0 Maybe it is n=
ot so bad. It will make</div><div>programmers all that more valuable. Or co=
st more time trying to get everything exactly correct,</div><div>because th=
ere might be an edge case where it is not clear what is ment.=C2=A0</div><d=
iv><br></div><div>What if I wanted to create &quot;machine_option i386[] =
=3D ( setup, ....);&quot; and pass the array to the include</div><div>funct=
ion?=C2=A0 (aside: This technique is not possible with 36 individual functi=
ons. 36 #define statements is not good).=C2=A0 Why do I have to include the=
 enum class name in each array member?=C2=A0 How do I pass this array to a =
function=C2=A0 &quot;server.include( machine_option::i386)&quot;?=C2=A0 =C2=
=A0It seems a bit redundant.=C2=A0 =C2=A0</div><div><br></div><div>I curren=
tly have an object that uses 6 enums) each=C2=A0 has a number of enumerator=
s runs for 3 to 12. How many individual functions would I need?). And why m=
ust my users remember which enum class with each enumerator. that goes to w=
hich function, and include its long name in addition to the value in the fu=
nction call. Will the misspelled enum class name-enumerator syntax cause mo=
re problems than the use of a common word like &quot;setup&quot;?=C2=A0 Stu=
dies have found the longer the word the greater the occurrence of misspelli=
ng it.=C2=A0 Should I name my enums &quot;a&quot;, &quot;b&quot;, &quot;c&q=
uot;, &quot;d&quot;, &quot;e&quot;, &quot;f&quot; ?=C2=A0</div><div>=C2=A0<=
/div><div>My thought is that there has to be a better way.=C2=A0=C2=A0</div=
><div><br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Fr=
i, Sep 14, 2018 at 2:02 PM Hyman Rosen &lt;<a onmousedown=3D"this.href=3D&#=
39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#=
39;;return true;" href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" g=
df-obfuscated-mailto=3D"r1q3zd7BBwAJ">hyman...@gmail.com</a>&gt; wrote:<br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_q=
uote"><div dir=3D"ltr">On Fri, Sep 14, 2018 at 2:58 PM Matthew Woehlke &lt;=
<a onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=
=3D"this.href=3D&#39;javascript:&#39;;return true;" href=3D"javascript:" ta=
rget=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"r1q3zd7BBwAJ">mwo=
ehlk...@gmail.com</a>&gt; wrote:</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Sure, this can be made to work in &quot;easy&quot; cases, but what about:<b=
r>
<br>
=C2=A0 enum class foo { TRICKY };<br>
=C2=A0 enum class bar { TRICKY };<br>
<br>
=C2=A0 void func(foo); // #1<br>
=C2=A0 void func(bar); // #2<br>
<br>
=C2=A0 func(TRICKY);<br>
<br>
Does the above call #1, #2, or neither?<br></blockquote><div><br>In Ada, th=
is would be a compilation error, since overloading (including return types)=
 fails<br>to resolve to a single interpretation.=C2=A0 If only one of the f=
unctions were visible, it would be<br>called with correct enumeration value=
..=C2=A0</div></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" o=
nclick=3D"this.href=3D&#39;javascript:&#39;;return true;" href=3D"javascrip=
t:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"r1q3zd7BBwA=
J">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a onmousedown=3D"this.href=3D&#39;jav=
ascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;re=
turn true;" href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obf=
uscated-mailto=3D"r1q3zd7BBwAJ">std-pr...@isocpp.org</a>.<br>
To view this discussion on the web visit <a onmousedown=3D"this.href=3D&#39=
;https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdaDcd_V=
-%3DFWtCPUm8NQmSfV%3DHTWB007ZRv3%3DwcGnFVuVA%40mail.gmail.com?utm_medium\x3=
demail\x26utm_source\x3dfooter&#39;;return true;" onclick=3D"this.href=3D&#=
39;https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdaDcd=
_V-%3DFWtCPUm8NQmSfV%3DHTWB007ZRv3%3DwcGnFVuVA%40mail.gmail.com?utm_medium\=
x3demail\x26utm_source\x3dfooter&#39;;return true;" href=3D"https://groups.=
google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdaDcd_V-%3DFWtCPUm8NQmS=
fV%3DHTWB007ZRv3%3DwcGnFVuVA%40mail.gmail.com?utm_medium=3Demail&amp;utm_so=
urce=3Dfooter" target=3D"_blank" rel=3D"nofollow">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/CAHSYqdaDcd_V-%<wbr>3DFWtCPUm=
8NQmSfV%<wbr>3DHTWB007ZRv3%3DwcGnFVuVA%<wbr>40mail.gmail.com</a>.<br>
</blockquote></div>
</blockquote></div>

<p></p>

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

------=_Part_1237_1327438137.1537013629885--

------=_Part_1236_771853165.1537013629885--

.

--000000000000b142390575ea57c7
Content-Type: text/plain; charset="UTF-8"

I see the possibility that Ada can detect the problem. The problem is
more complicated.

Suppose:

enum class  type-a: short { tricky = 10};
enum class type-b: double { tricky = 3.14 }
and
void  func ( type-a x) { ...}
void  func (type-b y} {....}

now which syntax is used in a call of  "func(tricky);"

Can you see the problem is deeper. It resides in the fact that both enums
have a common
enumerator; and a function with multiple syntax definitions that have a
enum in the same name
argument position, and there are no other arguments that can be used to
determine which syntax to use.

I have described the situation in a more exact way. The question is: can
the compiler detect that
situation and raise an error.   And is the trade-off of the exception code
worth making the
use of the function simpler/easier. The QnD solution was to include the
class qualifier in every reference
instance of an enum enumerator.  With this rule there is no possibility of
an error. Implementation
fits with the normal flow of the language (no real compiler exception
coding is required).

The same problem existed with the unscoped enum values. The solution was to
add the
class scoping qualifier.

The problem still exists in the unscoped enum where different types with a
multi-syntax
function names (just drop the "class/struct" attribute).

("There was an old lady who swallowed a fly. I don't know why she swallowed
the fly. Perhaps she'll die").
enum = fly; enum class qualifier = spider;  ??=bird; ...


On Sat, Sep 15, 2018 at 7:13 AM <mihailnajdenov@gmail.com> wrote:

> Note that this will make the code ever so slightly less type safe.
>
> enum class Abort { all };
> enum class Launch { all };
>
> void shuttle(Abort);
> void rocket(Launch);
>
> // user
>
> shuttle(all);
>
> Now if the user refactors rocket to shuttle, the code will silently change
> behavior. We introduce a problem even C does not have.
>
> Also note, this will be a compiler trick which will fail to work with
> forwarding and packing arguments into tuple.
>
>
> Having said that, there is proposal
> <http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p1099r0.html> to
> allow using an enum as it is a namespace, making the value(s) available
> with no qualification for the current scope.
>
>
> On Saturday, September 15, 2018 at 12:17:39 AM UTC+3, Lawrence Emke wrote:
>
>> In the case:
>>
>> enum class foo { TRICKY };
>>   enum class bar { TRICKY };
>>
>>   void func(foo); // #1
>>   void func(bar); // #2
>>
>> I see your point.
>>
>> In this case you will have to require the enum class name.
>> Can the compiler detect this situation where confusion can occur?
>> Can the compiler raise a warning to force you to specify the class in
>> this situation?
>>
>> if there is a function overload syntax situation in which enums are used,
>> can it possibly lead to
>> possible confusion because the enums have one or more common enumerators,
>> then
>> raise an error condition.
>>
>> As in all programming, if it is probabile (p>0) of an event is possible,
>> then it will happen, no matter how small the probability.  I understand
>> this is exception coding, and designers dislike any exception processing.
>>
>> I don't see that "assignment" has this edge case.  I don't see the edge
>> case  in a "switch" statement.
>>
>> The question is who is the audience for the compiler? We can make things
>> easy for
>> the designers or easy for the users (programmers). Who is serving who?
>> Is the edge case too important, too prevalent, too complicated to avoid the
>> exception code to flag the situation, and
>> choose the simplest solution of requiring the class name for every enum
>> class for every
>> enumerator reference.
>>
>> I went the road of having 3 non-argument functions for each bool
>> attribute in a class.
>> With 12 attributes there would be 36 individual functions, Using enums
>> there could be 3 functions.
>>
>> I don't talk like server.include(machine_option::setup).  I think in
>> terms of "server.include(setup)".
>> My thoughts are limited to then environment in which I am working.  To
>> have to go outside of
>> that and qualify what should be obvious, is a distractions.  Maybe it is
>> not so bad. It will make
>> programmers all that more valuable. Or cost more time trying to get
>> everything exactly correct,
>> because there might be an edge case where it is not clear what is ment.
>>
>> What if I wanted to create "machine_option i386[] = ( setup, ....);" and
>> pass the array to the include
>> function?  (aside: This technique is not possible with 36 individual
>> functions. 36 #define statements is not good).  Why do I have to include
>> the enum class name in each array member?  How do I pass this array to a
>> function  "server.include( machine_option::i386)"?   It seems a bit
>> redundant.
>>
>> I currently have an object that uses 6 enums) each  has a number of
>> enumerators runs for 3 to 12. How many individual functions would I need?).
>> And why must my users remember which enum class with each enumerator. that
>> goes to which function, and include its long name in addition to the value
>> in the function call. Will the misspelled enum class name-enumerator syntax
>> cause more problems than the use of a common word like "setup"?  Studies
>> have found the longer the word the greater the occurrence of misspelling
>> it.  Should I name my enums "a", "b", "c", "d", "e", "f" ?
>>
>> My thought is that there has to be a better way.
>>
>>
>> On Fri, Sep 14, 2018 at 2:02 PM Hyman Rosen <hyman...@gmail.com> wrote:
>>
>>> On Fri, Sep 14, 2018 at 2:58 PM Matthew Woehlke <mwoehlk...@gmail.com>
>>> wrote:
>>>
>>>> Sure, this can be made to work in "easy" cases, but what about:
>>>>
>>>>   enum class foo { TRICKY };
>>>>   enum class bar { TRICKY };
>>>>
>>>>   void func(foo); // #1
>>>>   void func(bar); // #2
>>>>
>>>>   func(TRICKY);
>>>>
>>>> Does the above call #1, #2, or neither?
>>>>
>>>
>>> In Ada, this would be a compilation error, since overloading (including
>>> return types) fails
>>> to resolve to a single interpretation.  If only one of the functions
>>> were visible, it would be
>>> called with correct enumeration value.
>>>
>>> --
>>> 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-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdaDcd_V-%3DFWtCPUm8NQmSfV%3DHTWB007ZRv3%3DwcGnFVuVA%40mail.gmail.com
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdaDcd_V-%3DFWtCPUm8NQmSfV%3DHTWB007ZRv3%3DwcGnFVuVA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/86bc9b0e-44fd-46fc-b6e3-349af0f9cc8e%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/86bc9b0e-44fd-46fc-b6e3-349af0f9cc8e%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BAqvO2ps2VX2DMnot4-mv2X9jbzTGtE8Nn3vbD6M%3D2gTBHG0Q%40mail.gmail.com.

--000000000000b142390575ea57c7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I see the possibility that Ada can detect the problem. The=
 problem is<div>more complicated.=C2=A0 =C2=A0</div><div><br></div><div>Sup=
pose:</div><div><br></div><div>enum class=C2=A0 type-a: short { tricky =3D =
10};</div><div>enum class type-b: double { tricky =3D 3.14 }</div><div>and<=
/div><div>void=C2=A0 func ( type-a x) { ...}</div><div>void=C2=A0 func (typ=
e-b y} {....}</div><div><br></div><div>now which syntax is used in a call o=
f=C2=A0 &quot;func(tricky);&quot;</div><div><br></div><div>Can you see the =
problem is deeper. It resides in the fact that both enums have a common</di=
v><div>enumerator; and a function with multiple syntax definitions that hav=
e a enum in the same name</div><div>argument position, and there are no oth=
er arguments that can be used to determine which syntax to use.</div><div>=
=C2=A0</div><div>I have described the situation in a more exact way. The qu=
estion is: can the compiler detect that</div><div>situation and raise an er=
ror.=C2=A0 =C2=A0And is the trade-off of the exception code worth making th=
e</div><div>use of the function simpler/easier. The QnD solution was to inc=
lude the class qualifier in every reference</div><div>instance of an enum e=
numerator.=C2=A0 With this rule there is no possibility of an error. Implem=
entation</div><div>fits with the normal flow of the language (no real compi=
ler exception coding is required).=C2=A0</div><div><br></div><div>The same =
problem existed with the unscoped enum values. The solution was to add the<=
/div><div>class scoping qualifier.</div><div><br></div><div>The problem sti=
ll exists in the unscoped enum where different types with a multi-syntax</d=
iv><div>function names (just drop the &quot;class/struct&quot; attribute).=
=C2=A0</div><div><br></div><div>(&quot;There was an old lady who swallowed =
a fly. I don&#39;t know why she swallowed the fly. Perhaps she&#39;ll die&q=
uot;).</div><div>enum =3D fly; enum class qualifier =3D spider;=C2=A0 ??=3D=
bird; ...=C2=A0<br></div><div><br></div></div><br><div class=3D"gmail_quote=
"><div dir=3D"ltr">On Sat, Sep 15, 2018 at 7:13 AM &lt;<a href=3D"mailto:mi=
hailnajdenov@gmail.com">mihailnajdenov@gmail.com</a>&gt; wrote:<br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Note that this will make=
 the code ever so slightly less type safe.</div><div><br></div><div><font f=
ace=3D"courier new,monospace">enum class Abort { all };<br>enum class Launc=
h { all };</font></div><div><font face=3D"courier new,monospace"></font><br=
></div><div><font face=3D"courier new,monospace">void shuttle(Abort);<br>vo=
id rocket(Launch);=C2=A0</font></div><div><font face=3D"courier new,monospa=
ce"></font><br></div><div><font face=3D"courier new,monospace">// user</fon=
t></div><div><font face=3D"courier new,monospace"></font><br></div><div><fo=
nt face=3D"courier new,monospace"><span style=3D"display:inline!important;f=
loat:none;background-color:transparent;color:rgb(34,34,34);font-family:cour=
ier new,monospace;font-size:13px;font-style:normal;font-variant:normal;font=
-weight:400;letter-spacing:normal;text-align:left;text-decoration:none;text=
-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">shuttl=
e</span>(all);</font></div><div><font face=3D"courier new,monospace"></font=
><b></b><i></i><u></u><sub></sub><sup></sup><strike></strike><font face=3D"=
courier new,monospace"></font><br></div><div>Now if the user refactors rock=
et to shuttle, the code will silently change behavior. We introduce a probl=
em even C does not have.</div><div><br></div><div>Also note, this will be a=
 compiler trick which will fail to work with forwarding and packing argumen=
ts into tuple.</div><div><br></div><div><br></div><div>Having said that, <a=
 href=3D"http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p1099r0.ht=
ml" target=3D"_blank">there is proposal</a> to allow <font face=3D"courier =
new,monospace">using</font><font face=3D"arial,sans-serif"> an enum as it i=
s a namespace, making the value(s) available with no qualification for the =
current scope.=C2=A0</font></div><div><font face=3D"courier new,monospace">=
</font><font face=3D"arial,sans-serif"></font><br></div><div><br></div><div=
>On Saturday, September 15, 2018 at 12:17:39 AM UTC+3, Lawrence Emke wrote:=
</div><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">In the case:=
<div><br></div><div><span style=3D"color:rgb(80,0,80)">enum class foo { TRI=
CKY };</span><br style=3D"color:rgb(80,0,80)"><span style=3D"color:rgb(80,0=
,80)">=C2=A0 enum class bar { TRICKY };</span><br style=3D"color:rgb(80,0,8=
0)"><br style=3D"color:rgb(80,0,80)"><span style=3D"color:rgb(80,0,80)">=C2=
=A0 void func(foo); // #1</span><br style=3D"color:rgb(80,0,80)"><span styl=
e=3D"color:rgb(80,0,80)">=C2=A0 void func(bar); // #2</span><br style=3D"co=
lor:rgb(80,0,80)"></div><div><br></div><div>I see your point.=C2=A0</div><d=
iv><br></div><div>In this case you will have to require the enum class name=
..=C2=A0</div><div>Can the compiler detect this situation where confusion ca=
n occur?=C2=A0</div><div>Can the compiler raise a warning to force you to s=
pecify the class in this situation?=C2=A0</div><div><br></div><div>if there=
 is a function overload syntax situation in which enums are used, can it po=
ssibly lead to</div><div>possible confusion because the enums have one or m=
ore common enumerators, then</div><div>raise an error condition.=C2=A0=C2=
=A0</div><div><br></div><div>As in all programming, if it is probabile (p&g=
t;0) of an event is possible, then it will happen, no matter how small the =
probability.=C2=A0 I understand this is exception coding, and designers dis=
like any exception processing.=C2=A0=C2=A0</div><div><br></div><div>I don&#=
39;t see that &quot;assignment&quot; has this edge case.=C2=A0 I don&#39;t =
see the edge case=C2=A0 in a &quot;switch&quot; statement.</div><div><br></=
div><div>The question is who is the audience for the compiler? We can make =
things easy for</div><div>the designers or easy for the users (programmers)=
.. Who is serving who?=C2=A0 Is the edge case too important, too prevalent, =
too complicated to avoid the exception code to flag the situation, and</div=
><div>choose the simplest solution of requiring the class name for every en=
um class for every</div><div>enumerator reference.=C2=A0=C2=A0</div><div><b=
r></div><div>I went the road of having 3 non-argument functions for each bo=
ol attribute in a class.=C2=A0</div><div>With 12 attributes there would be =
36 individual functions, Using enums there could be 3 functions.</div><div>=
<br></div><div>I don&#39;t talk like server.include(machine_option::setup).=
=C2=A0 I think in terms of &quot;server.include(setup)&quot;.</div><div>My =
thoughts are limited to then environment in which I am working.=C2=A0 To ha=
ve to go outside of</div><div>that and qualify what should be obvious, is a=
 distractions.=C2=A0 Maybe it is not so bad. It will make</div><div>program=
mers all that more valuable. Or cost more time trying to get everything exa=
ctly correct,</div><div>because there might be an edge case where it is not=
 clear what is ment.=C2=A0</div><div><br></div><div>What if I wanted to cre=
ate &quot;machine_option i386[] =3D ( setup, ....);&quot; and pass the arra=
y to the include</div><div>function?=C2=A0 (aside: This technique is not po=
ssible with 36 individual functions. 36 #define statements is not good).=C2=
=A0 Why do I have to include the enum class name in each array member?=C2=
=A0 How do I pass this array to a function=C2=A0 &quot;server.include( mach=
ine_option::i386)&quot;?=C2=A0 =C2=A0It seems a bit redundant.=C2=A0 =C2=A0=
</div><div><br></div><div>I currently have an object that uses 6 enums) eac=
h=C2=A0 has a number of enumerators runs for 3 to 12. How many individual f=
unctions would I need?). And why must my users remember which enum class wi=
th each enumerator. that goes to which function, and include its long name =
in addition to the value in the function call. Will the misspelled enum cla=
ss name-enumerator syntax cause more problems than the use of a common word=
 like &quot;setup&quot;?=C2=A0 Studies have found the longer the word the g=
reater the occurrence of misspelling it.=C2=A0 Should I name my enums &quot=
;a&quot;, &quot;b&quot;, &quot;c&quot;, &quot;d&quot;, &quot;e&quot;, &quot=
;f&quot; ?=C2=A0</div><div>=C2=A0</div><div>My thought is that there has to=
 be a better way.=C2=A0=C2=A0</div><div><br></div></div><br><div class=3D"g=
mail_quote"><div dir=3D"ltr">On Fri, Sep 14, 2018 at 2:02 PM Hyman Rosen &l=
t;<a rel=3D"nofollow">hyman...@gmail.com</a>&gt; wrote:<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=
=3D"ltr">On Fri, Sep 14, 2018 at 2:58 PM Matthew Woehlke &lt;<a rel=3D"nofo=
llow">mwoehlk...@gmail.com</a>&gt; wrote:</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x">
Sure, this can be made to work in &quot;easy&quot; cases, but what about:<b=
r>
<br>
=C2=A0 enum class foo { TRICKY };<br>
=C2=A0 enum class bar { TRICKY };<br>
<br>
=C2=A0 void func(foo); // #1<br>
=C2=A0 void func(bar); // #2<br>
<br>
=C2=A0 func(TRICKY);<br>
<br>
Does the above call #1, #2, or neither?<br></blockquote><div><br>In Ada, th=
is would be a compilation error, since overloading (including return types)=
 fails<br>to resolve to a single interpretation.=C2=A0 If only one of the f=
unctions were visible, it would be<br>called with correct enumeration value=
..=C2=A0</div></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</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/CAHSYqdaDcd_V-%3DFWtCPUm8NQmSfV%3DHTW=
B007ZRv3%3DwcGnFVuVA%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Df=
ooter" rel=3D"nofollow" target=3D"_blank">https://groups.google.com/a/isocp=
p.org/d/msgid/std-proposals/CAHSYqdaDcd_V-%3DFWtCPUm8NQmSfV%3DHTWB007ZRv3%3=
DwcGnFVuVA%40mail.gmail.com</a>.<br>
</blockquote></div>
</blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">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/86bc9b0e-44fd-46fc-b6e3-349af0f9cc8e%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/86bc9b0e-44fd-=
46fc-b6e3-349af0f9cc8e%40isocpp.org</a>.<br>
</blockquote></div>

<p></p>

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

--000000000000b142390575ea57c7--

.

--000000000000e1c3520575ec3f01
Content-Type: text/plain; charset="UTF-8"

I wonder if the problem with enums is related to "using one thing for two
or more purposes"?
(Is it like using SSN as both a Soc Sec id and a driver's license id - not
a good design idea).
With the introduction of the "type" attribute, another purpose is being
added.

If all enums are only integers then the problem would be easy. Like in Ada,
the two versions of "func" would have identical signatures.

What is the purpose of an enum? A: a list of valid defined "names", within
the enum context the value of the enumerator is not very important.

Another purpose is to provide a list of known constant values which can be
identified by name.  Here the value of the enumerator is very important.

It seems when the constant value is more important, then there should not be
multiple definitions of the same constant.  The same name should not exist
in two different constant name lists. When the name is more important
than the value, then the name can be repeated in multiple valueless lists.

So if "tricky" as an important value, it should occur only once. If the
value is
not important then it can be defined in multiple lists. non-unique value
lists
should be treated as the same type (e.g. "int").  all uniquely valued lists
can
be treated as their subtype. If "tricky" is defined as a unique constant
type value
then it should only appear in one unique value list, and not in any
non-unique value list.
If both versions of "func" name different uniquely valued lists, then
"tricky" will appear in only one of them. For two non-uniquely valued lists
both lists have the same syntax, so their definition is invalid.

Just an idea.





On Sat, Sep 15, 2018 at 10:10 AM Lawrence Emke <lawrence.emke@gmail.com>
wrote:

> I see the possibility that Ada can detect the problem. The problem is
> more complicated.
>
> Suppose:
>
> enum class  type-a: short { tricky = 10};
> enum class type-b: double { tricky = 3.14 }
> and
> void  func ( type-a x) { ...}
> void  func (type-b y} {....}
>
> now which syntax is used in a call of  "func(tricky);"
>
> Can you see the problem is deeper. It resides in the fact that both enums
> have a common
> enumerator; and a function with multiple syntax definitions that have a
> enum in the same name
> argument position, and there are no other arguments that can be used to
> determine which syntax to use.
>
> I have described the situation in a more exact way. The question is: can
> the compiler detect that
> situation and raise an error.   And is the trade-off of the exception code
> worth making the
> use of the function simpler/easier. The QnD solution was to include the
> class qualifier in every reference
> instance of an enum enumerator.  With this rule there is no possibility of
> an error. Implementation
> fits with the normal flow of the language (no real compiler exception
> coding is required).
>
> The same problem existed with the unscoped enum values. The solution was
> to add the
> class scoping qualifier.
>
> The problem still exists in the unscoped enum where different types with a
> multi-syntax
> function names (just drop the "class/struct" attribute).
>
> ("There was an old lady who swallowed a fly. I don't know why she
> swallowed the fly. Perhaps she'll die").
> enum = fly; enum class qualifier = spider;  ??=bird; ...
>
>
> On Sat, Sep 15, 2018 at 7:13 AM <mihailnajdenov@gmail.com> wrote:
>
>> Note that this will make the code ever so slightly less type safe.
>>
>> enum class Abort { all };
>> enum class Launch { all };
>>
>> void shuttle(Abort);
>> void rocket(Launch);
>>
>> // user
>>
>> shuttle(all);
>>
>> Now if the user refactors rocket to shuttle, the code will silently
>> change behavior. We introduce a problem even C does not have.
>>
>> Also note, this will be a compiler trick which will fail to work with
>> forwarding and packing arguments into tuple.
>>
>>
>> Having said that, there is proposal
>> <http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p1099r0.html>
>> to allow using an enum as it is a namespace, making the value(s)
>> available with no qualification for the current scope.
>>
>>
>> On Saturday, September 15, 2018 at 12:17:39 AM UTC+3, Lawrence Emke wrote:
>>
>>> In the case:
>>>
>>> enum class foo { TRICKY };
>>>   enum class bar { TRICKY };
>>>
>>>   void func(foo); // #1
>>>   void func(bar); // #2
>>>
>>> I see your point.
>>>
>>> In this case you will have to require the enum class name.
>>> Can the compiler detect this situation where confusion can occur?
>>> Can the compiler raise a warning to force you to specify the class in
>>> this situation?
>>>
>>> if there is a function overload syntax situation in which enums are
>>> used, can it possibly lead to
>>> possible confusion because the enums have one or more common
>>> enumerators, then
>>> raise an error condition.
>>>
>>> As in all programming, if it is probabile (p>0) of an event is possible,
>>> then it will happen, no matter how small the probability.  I understand
>>> this is exception coding, and designers dislike any exception processing.
>>>
>>> I don't see that "assignment" has this edge case.  I don't see the edge
>>> case  in a "switch" statement.
>>>
>>> The question is who is the audience for the compiler? We can make things
>>> easy for
>>> the designers or easy for the users (programmers). Who is serving who?
>>> Is the edge case too important, too prevalent, too complicated to avoid the
>>> exception code to flag the situation, and
>>> choose the simplest solution of requiring the class name for every enum
>>> class for every
>>> enumerator reference.
>>>
>>> I went the road of having 3 non-argument functions for each bool
>>> attribute in a class.
>>> With 12 attributes there would be 36 individual functions, Using enums
>>> there could be 3 functions.
>>>
>>> I don't talk like server.include(machine_option::setup).  I think in
>>> terms of "server.include(setup)".
>>> My thoughts are limited to then environment in which I am working.  To
>>> have to go outside of
>>> that and qualify what should be obvious, is a distractions.  Maybe it is
>>> not so bad. It will make
>>> programmers all that more valuable. Or cost more time trying to get
>>> everything exactly correct,
>>> because there might be an edge case where it is not clear what is ment.
>>>
>>> What if I wanted to create "machine_option i386[] = ( setup, ....);" and
>>> pass the array to the include
>>> function?  (aside: This technique is not possible with 36 individual
>>> functions. 36 #define statements is not good).  Why do I have to include
>>> the enum class name in each array member?  How do I pass this array to a
>>> function  "server.include( machine_option::i386)"?   It seems a bit
>>> redundant.
>>>
>>> I currently have an object that uses 6 enums) each  has a number of
>>> enumerators runs for 3 to 12. How many individual functions would I need?).
>>> And why must my users remember which enum class with each enumerator. that
>>> goes to which function, and include its long name in addition to the value
>>> in the function call. Will the misspelled enum class name-enumerator syntax
>>> cause more problems than the use of a common word like "setup"?  Studies
>>> have found the longer the word the greater the occurrence of misspelling
>>> it.  Should I name my enums "a", "b", "c", "d", "e", "f" ?
>>>
>>> My thought is that there has to be a better way.
>>>
>>>
>>> On Fri, Sep 14, 2018 at 2:02 PM Hyman Rosen <hyman...@gmail.com> wrote:
>>>
>>>> On Fri, Sep 14, 2018 at 2:58 PM Matthew Woehlke <mwoehlk...@gmail.com>
>>>> wrote:
>>>>
>>>>> Sure, this can be made to work in "easy" cases, but what about:
>>>>>
>>>>>   enum class foo { TRICKY };
>>>>>   enum class bar { TRICKY };
>>>>>
>>>>>   void func(foo); // #1
>>>>>   void func(bar); // #2
>>>>>
>>>>>   func(TRICKY);
>>>>>
>>>>> Does the above call #1, #2, or neither?
>>>>>
>>>>
>>>> In Ada, this would be a compilation error, since overloading (including
>>>> return types) fails
>>>> to resolve to a single interpretation.  If only one of the functions
>>>> were visible, it would be
>>>> called with correct enumeration value.
>>>>
>>>> --
>>>> 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-proposal...@isocpp.org.
>>>> To post to this group, send email to std-pr...@isocpp.org.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdaDcd_V-%3DFWtCPUm8NQmSfV%3DHTWB007ZRv3%3DwcGnFVuVA%40mail.gmail.com
>>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdaDcd_V-%3DFWtCPUm8NQmSfV%3DHTWB007ZRv3%3DwcGnFVuVA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/86bc9b0e-44fd-46fc-b6e3-349af0f9cc8e%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/86bc9b0e-44fd-46fc-b6e3-349af0f9cc8e%40isocpp.org?utm_medium=email&utm_source=footer>
>> .
>>
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BAqvO1rqOTc_FSqCmf7HADZa7ocuS1ED6AWTUuxYAkwSHLOpA%40mail.gmail.com.

--000000000000e1c3520575ec3f01
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I wonder if the problem with enums is related to &quot;usi=
ng one thing for two or more purposes&quot;?=C2=A0<div>(Is it like using SS=
N as both a Soc Sec id and a driver&#39;s license id - not a good design id=
ea).<br><div>With the introduction of the &quot;type&quot; attribute, anoth=
er purpose is being added.=C2=A0</div><div><br></div><div>If all enums are =
only integers then the problem would be easy. Like in Ada,</div><div>the tw=
o versions of &quot;func&quot; would have identical signatures.=C2=A0 =C2=
=A0</div><div><div><br></div></div><div>What is the purpose of an enum? A: =
a list of valid defined &quot;names&quot;, within</div><div>the enum contex=
t the value of the enumerator is not very important.=C2=A0</div><div><br></=
div><div>Another purpose is to provide a list of known constant values whic=
h can be</div><div>identified by name.=C2=A0 Here the value of the enumerat=
or is very important.=C2=A0</div><div><br></div><div>It seems when the cons=
tant value is more important, then there should not be</div><div>multiple d=
efinitions of the same constant.=C2=A0 The same name should not exist</div>=
<div>in two different constant name lists. When the name is more important<=
/div><div>than the value, then the name can be repeated in multiple valuele=
ss lists.=C2=A0</div><div><br></div><div>So if &quot;tricky&quot; as an imp=
ortant value, it should occur only once. If the value is</div><div>not impo=
rtant then it can be defined in multiple lists. non-unique value lists</div=
><div>should be treated as the same type (e.g. &quot;int&quot;).=C2=A0 all =
uniquely valued lists can</div><div>be treated as their subtype. If &quot;t=
ricky&quot; is defined as a unique constant type value</div><div>then it sh=
ould only appear in one unique value list, and not in any non-unique value =
list.</div><div>If both versions of &quot;func&quot; name different uniquel=
y valued lists, then &quot;tricky&quot; will appear in only one of them. Fo=
r two non-uniquely valued lists both lists have the same syntax, so their d=
efinition is invalid.=C2=A0</div><div><br></div><div>Just an idea.=C2=A0</d=
iv><div><br></div><div><br></div><div><br></div><div><br></div></div></div>=
<br><div class=3D"gmail_quote"><div dir=3D"ltr">On Sat, Sep 15, 2018 at 10:=
10 AM Lawrence Emke &lt;<a href=3D"mailto:lawrence.emke@gmail.com" target=
=3D"_blank">lawrence.emke@gmail.com</a>&gt; wrote:<br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr">I see the possibility that Ada can detect =
the problem. The problem is<div>more complicated.=C2=A0 =C2=A0</div><div><b=
r></div><div>Suppose:</div><div><br></div><div>enum class=C2=A0 type-a: sho=
rt { tricky =3D 10};</div><div>enum class type-b: double { tricky =3D 3.14 =
}</div><div>and</div><div>void=C2=A0 func ( type-a x) { ...}</div><div>void=
=C2=A0 func (type-b y} {....}</div><div><br></div><div>now which syntax is =
used in a call of=C2=A0 &quot;func(tricky);&quot;</div><div><br></div><div>=
Can you see the problem is deeper. It resides in the fact that both enums h=
ave a common</div><div>enumerator; and a function with multiple syntax defi=
nitions that have a enum in the same name</div><div>argument position, and =
there are no other arguments that can be used to determine which syntax to =
use.</div><div>=C2=A0</div><div>I have described the situation in a more ex=
act way. The question is: can the compiler detect that</div><div>situation =
and raise an error.=C2=A0 =C2=A0And is the trade-off of the exception code =
worth making the</div><div>use of the function simpler/easier. The QnD solu=
tion was to include the class qualifier in every reference</div><div>instan=
ce of an enum enumerator.=C2=A0 With this rule there is no possibility of a=
n error. Implementation</div><div>fits with the normal flow of the language=
 (no real compiler exception coding is required).=C2=A0</div><div><br></div=
><div>The same problem existed with the unscoped enum values. The solution =
was to add the</div><div>class scoping qualifier.</div><div><br></div><div>=
The problem still exists in the unscoped enum where different types with a =
multi-syntax</div><div>function names (just drop the &quot;class/struct&quo=
t; attribute).=C2=A0</div><div><br></div><div>(&quot;There was an old lady =
who swallowed a fly. I don&#39;t know why she swallowed the fly. Perhaps sh=
e&#39;ll die&quot;).</div><div>enum =3D fly; enum class qualifier =3D spide=
r;=C2=A0 ??=3Dbird; ...=C2=A0<br></div><div><br></div></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr">On Sat, Sep 15, 2018 at 7:13 AM &lt;<a hr=
ef=3D"mailto:mihailnajdenov@gmail.com" target=3D"_blank">mihailnajdenov@gma=
il.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr"><div>Note that this will make the code ever so slightly less type safe.=
</div><div><br></div><div><font face=3D"courier new,monospace">enum class A=
bort { all };<br>enum class Launch { all };</font></div><div><font face=3D"=
courier new,monospace"></font><br></div><div><font face=3D"courier new,mono=
space">void shuttle(Abort);<br>void rocket(Launch);=C2=A0</font></div><div>=
<font face=3D"courier new,monospace"></font><br></div><div><font face=3D"co=
urier new,monospace">// user</font></div><div><font face=3D"courier new,mon=
ospace"></font><br></div><div><font face=3D"courier new,monospace"><span st=
yle=3D"display:inline!important;float:none;background-color:transparent;col=
or:rgb(34,34,34);font-family:courier new,monospace;font-size:13px;font-styl=
e:normal;font-variant:normal;font-weight:400;letter-spacing:normal;text-ali=
gn:left;text-decoration:none;text-indent:0px;text-transform:none;white-spac=
e:normal;word-spacing:0px">shuttle</span>(all);</font></div><div><font face=
=3D"courier new,monospace"></font><b></b><i></i><u></u><sub></sub><sup></su=
p><strike></strike><font face=3D"courier new,monospace"></font><br></div><d=
iv>Now if the user refactors rocket to shuttle, the code will silently chan=
ge behavior. We introduce a problem even C does not have.</div><div><br></d=
iv><div>Also note, this will be a compiler trick which will fail to work wi=
th forwarding and packing arguments into tuple.</div><div><br></div><div><b=
r></div><div>Having said that, <a href=3D"http://www.open-std.org/JTC1/SC22=
/WG21/docs/papers/2018/p1099r0.html" target=3D"_blank">there is proposal</a=
> to allow <font face=3D"courier new,monospace">using</font><font face=3D"a=
rial,sans-serif"> an enum as it is a namespace, making the value(s) availab=
le with no qualification for the current scope.=C2=A0</font></div><div><fon=
t face=3D"courier new,monospace"></font><font face=3D"arial,sans-serif"></f=
ont><br></div><div><br></div><div>On Saturday, September 15, 2018 at 12:17:=
39 AM UTC+3, Lawrence Emke wrote:</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr">In the case:<div><br></div><div><span style=3D"color:r=
gb(80,0,80)">enum class foo { TRICKY };</span><br style=3D"color:rgb(80,0,8=
0)"><span style=3D"color:rgb(80,0,80)">=C2=A0 enum class bar { TRICKY };</s=
pan><br style=3D"color:rgb(80,0,80)"><br style=3D"color:rgb(80,0,80)"><span=
 style=3D"color:rgb(80,0,80)">=C2=A0 void func(foo); // #1</span><br style=
=3D"color:rgb(80,0,80)"><span style=3D"color:rgb(80,0,80)">=C2=A0 void func=
(bar); // #2</span><br style=3D"color:rgb(80,0,80)"></div><div><br></div><d=
iv>I see your point.=C2=A0</div><div><br></div><div>In this case you will h=
ave to require the enum class name.=C2=A0</div><div>Can the compiler detect=
 this situation where confusion can occur?=C2=A0</div><div>Can the compiler=
 raise a warning to force you to specify the class in this situation?=C2=A0=
</div><div><br></div><div>if there is a function overload syntax situation =
in which enums are used, can it possibly lead to</div><div>possible confusi=
on because the enums have one or more common enumerators, then</div><div>ra=
ise an error condition.=C2=A0=C2=A0</div><div><br></div><div>As in all prog=
ramming, if it is probabile (p&gt;0) of an event is possible, then it will =
happen, no matter how small the probability.=C2=A0 I understand this is exc=
eption coding, and designers dislike any exception processing.=C2=A0=C2=A0<=
/div><div><br></div><div>I don&#39;t see that &quot;assignment&quot; has th=
is edge case.=C2=A0 I don&#39;t see the edge case=C2=A0 in a &quot;switch&q=
uot; statement.</div><div><br></div><div>The question is who is the audienc=
e for the compiler? We can make things easy for</div><div>the designers or =
easy for the users (programmers). Who is serving who?=C2=A0 Is the edge cas=
e too important, too prevalent, too complicated to avoid the exception code=
 to flag the situation, and</div><div>choose the simplest solution of requi=
ring the class name for every enum class for every</div><div>enumerator ref=
erence.=C2=A0=C2=A0</div><div><br></div><div>I went the road of having 3 no=
n-argument functions for each bool attribute in a class.=C2=A0</div><div>Wi=
th 12 attributes there would be 36 individual functions, Using enums there =
could be 3 functions.</div><div><br></div><div>I don&#39;t talk like server=
..include(machine_option::setup).=C2=A0 I think in terms of &quot;server.inc=
lude(setup)&quot;.</div><div>My thoughts are limited to then environment in=
 which I am working.=C2=A0 To have to go outside of</div><div>that and qual=
ify what should be obvious, is a distractions.=C2=A0 Maybe it is not so bad=
.. It will make</div><div>programmers all that more valuable. Or cost more t=
ime trying to get everything exactly correct,</div><div>because there might=
 be an edge case where it is not clear what is ment.=C2=A0</div><div><br></=
div><div>What if I wanted to create &quot;machine_option i386[] =3D ( setup=
, ....);&quot; and pass the array to the include</div><div>function?=C2=A0 =
(aside: This technique is not possible with 36 individual functions. 36 #de=
fine statements is not good).=C2=A0 Why do I have to include the enum class=
 name in each array member?=C2=A0 How do I pass this array to a function=C2=
=A0 &quot;server.include( machine_option::i386)&quot;?=C2=A0 =C2=A0It seems=
 a bit redundant.=C2=A0 =C2=A0</div><div><br></div><div>I currently have an=
 object that uses 6 enums) each=C2=A0 has a number of enumerators runs for =
3 to 12. How many individual functions would I need?). And why must my user=
s remember which enum class with each enumerator. that goes to which functi=
on, and include its long name in addition to the value in the function call=
.. Will the misspelled enum class name-enumerator syntax cause more problems=
 than the use of a common word like &quot;setup&quot;?=C2=A0 Studies have f=
ound the longer the word the greater the occurrence of misspelling it.=C2=
=A0 Should I name my enums &quot;a&quot;, &quot;b&quot;, &quot;c&quot;, &qu=
ot;d&quot;, &quot;e&quot;, &quot;f&quot; ?=C2=A0</div><div>=C2=A0</div><div=
>My thought is that there has to be a better way.=C2=A0=C2=A0</div><div><br=
></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, Sep 14=
, 2018 at 2:02 PM Hyman Rosen &lt;<a rel=3D"nofollow">hyman...@gmail.com</a=
>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div =
class=3D"gmail_quote"><div dir=3D"ltr">On Fri, Sep 14, 2018 at 2:58 PM Matt=
hew Woehlke &lt;<a rel=3D"nofollow">mwoehlk...@gmail.com</a>&gt; wrote:</di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex">
Sure, this can be made to work in &quot;easy&quot; cases, but what about:<b=
r>
<br>
=C2=A0 enum class foo { TRICKY };<br>
=C2=A0 enum class bar { TRICKY };<br>
<br>
=C2=A0 void func(foo); // #1<br>
=C2=A0 void func(bar); // #2<br>
<br>
=C2=A0 func(TRICKY);<br>
<br>
Does the above call #1, #2, or neither?<br></blockquote><div><br>In Ada, th=
is would be a compilation error, since overloading (including return types)=
 fails<br>to resolve to a single interpretation.=C2=A0 If only one of the f=
unctions were visible, it would be<br>called with correct enumeration value=
..=C2=A0</div></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</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/CAHSYqdaDcd_V-%3DFWtCPUm8NQmSfV%3DHTW=
B007ZRv3%3DwcGnFVuVA%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Df=
ooter" rel=3D"nofollow" target=3D"_blank">https://groups.google.com/a/isocp=
p.org/d/msgid/std-proposals/CAHSYqdaDcd_V-%3DFWtCPUm8NQmSfV%3DHTWB007ZRv3%3=
DwcGnFVuVA%40mail.gmail.com</a>.<br>
</blockquote></div>
</blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">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/86bc9b0e-44fd-46fc-b6e3-349af0f9cc8e%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/86bc9b0e-44fd-=
46fc-b6e3-349af0f9cc8e%40isocpp.org</a>.<br>
</blockquote></div>
</blockquote></div>

<p></p>

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

--000000000000e1c3520575ec3f01--

.

On 2018-09-14 17:17, Lawrence Emke wrote:
> In the case:
>
> enum class foo { TRICKY };
>   enum class bar { TRICKY };
>
>   void func(foo); // #1
>   void func(bar); // #2
>
> I see your point.
>
> In this case you will have to require the enum class name.
> Can the compiler detect this situation where confusion can occur?
> Can the compiler raise a warning to force you to specify the class in this
> situation?

Maybe.

I still think the real challenge is that the compiler doesn't know the
type of `TRICKY` until it has performed overload resolution... which it
"can't do" because it doesn't know the type of `TRICKY`.

In order to make this work, the compiler would have to generate a set of
overload candidates, then use those to try to resolve what `TRICKY`
means, then go back and try to plug those into the overloads, and hope
that, eventually, this resolves down into a single, unambiguous call.

This feels like it *might* be tricky to implement, which is probably why
there hasn't been much progress on any proposal to implement this, and
why I think it would be tremendously helpful if someone could produce a
working implementation. Any such attempt should also include coming up
with as many "pathological" cases as possible and showing that they
behave reasonably (which probably includes the compiler throwing an
error for cases that can't be uniquely resolved).

> The question is who is the audience for the compiler? We can make
> things easy for the designers or easy for the users (programmers).
> Who is serving who?
Sure, but if a feature *can't* be implemented, or is unreasonably
difficult to implement, that's a problem.

I'm not *convinced* that's the case. I just suspect there is concern
that it *might* be the case, which is making folks hesitant. This is why
I think implementation experience would be tremendously helpful for any
proposal for this feature.

Please understand, I'm *not* trying to say "this is a stupid feature
that you shouldn't pursue". This is a potentially interesting feature
and you are not the only one interested in it. *However*, it doesn't
seem to have gained traction. What I am trying to express is why I think
that has been the case, and what can be done to move it forward.

That said, Mihail also makes a good point...

--
Matthew

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/45bebe5d-695d-2ec9-0ac3-523b2dd7225d%40gmail.com.

.

--00000000000099ada80576141cf6
Content-Type: text/plain; charset="UTF-8"

On Mon, Sep 17, 2018 at 11:59 AM Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> In order to make this work, the compiler would have to generate a set of
> overload candidates, then use those to try to resolve what `TRICKY`
> means, then go back and try to plug those into the overloads, and hope
> that, eventually, this resolves down into a single, unambiguous call.
>

Yep.  In Ada, it's a two-pass algorithm.  Here's how:
<https://www2.adacore.com/gap-static/GNAT_Book/html/node10.htm>
It also includes overload resolution involving named parameters.

--
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/CAHSYqdYXqAKtvYbwCxscN6VCJd9uihoEJZJdoY1MOrGH18WPDg%40mail.gmail.com.

--00000000000099ada80576141cf6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"lt=
r">On Mon, Sep 17, 2018 at 11:59 AM Matthew Woehlke &lt;<a href=3D"mailto:m=
woehlke.floss@gmail.com">mwoehlke.floss@gmail.com</a>&gt; wrote:</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex">
In order to make this work, the compiler would have to generate a set of<br=
>
overload candidates, then use those to try to resolve what `TRICKY`<br>
means, then go back and try to plug those into the overloads, and hope<br>
that, eventually, this resolves down into a single, unambiguous call.<br></=
blockquote><div><br>Yep.=C2=A0 In Ada, it&#39;s a two-pass algorithm.=C2=A0=
 Here&#39;s how:<br>&lt;<a href=3D"https://www2.adacore.com/gap-static/GNAT=
_Book/html/node10.htm">https://www2.adacore.com/gap-static/GNAT_Book/html/n=
ode10.htm</a>&gt;<br>It also includes overload resolution involving named p=
arameters.</div></div></div></div>

<p></p>

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

--00000000000099ada80576141cf6--

.