------=_Part_597_33539223.1402427523643
Content-Type: text/plain; charset=UTF-8

Hi guys

I'm not a compiler writer or have any experience designing languages, I am
basically just an ordinary C++ user. So this proposal might not be up to
the detail you'd might expect. Anyways...

The idea is to have "local enums" in function calls as syntactic sugar, so
that it becomes easier to write clear interfaces in C++, something that
good programmers already do, but which often involves a lot of extra typing
and cluttering the namespace with lots and lots of additional enums, that
have no use outside of that one function.

Here is the general concept:


void Func1(enum {DoFoo, DoBar} Param1) // Param1 is just an int, the enum
is syntactic sugar
{
  if (Param == DoFoo)
  { ... }
}

void Func2(int Param1) { ... } // invalid, same type

Func1(DoFoo); // compiler knows that Param1 is an enum in the scope of
Func1, substitutes DoFoo with 0
Func1(0); // same as DoFoo
Func1(1); // same as DoBar

enum{DidFoo, DidBar} Func3() // again, return value is just an int
{
  return DidFoo; // just returns 0
}

if (Func3() == Func3::DidFoo) ... // for the return value, Func3 acts like
an 'enum class'


void Func4(enum {DoFoo = 0, DoBar = 1} Param1, enum {DoFoo = 2, DoBar = 3}
Param2) // compiler error, DoFoo and DoBar may only be defined once across
all parameters
{
  if (Param1 == DoFoo) // which one? -> therefore not allowed
  ...
}

enum {DidFoo, DidBar} Func4(enum {DoFoo = 0, DoBar = 1} Param1)
{
  return Param1; // implicitely casts to the return 'type' (int), so this
would return 0 or 1
  // well, actually both the return type and Param1 are alread int, so no
real cast is done
}

auto ret = Func4(DoFoo /* 0 */);
// ret is of type int
// you can either compare it with 0, 1, etc. or with the 'enum values'
Func4::DidFoo and Func4::DidBar

// outside of the function call parenthesis, Func4::DoFoo and Func4::DoBar
do not exist! (this is THE crucial feature)

Func1(Func4::DoFoo);  // compiler error, 'Func4::DoFoo' unknown type
Func1(Func4::DidFoo); // probably ok, the return enum type of Func4 needs
to be globally accessible

// actually for the return type one could just leave this feature out, and
say one has to create a real enum for this, since it would need to be
globally accessible
// but for consistency it would probably be nice to have it still


// Reasoning:

// BAD:

  void DeleteFile(bool bRecursive);
  DeleteFile(false); // um, what?

// BETTER:

  enum DeleteFileOptions { Recursive, NonRecursive };
  void DeleteFile(DeleteFileOptions option);
  DeleteFile(Recursive); // ah!,
  // but so much typing, also DeleteFileOptions is now globally accessible
and can
  // a) conflict with other stuff and
  // b) reused where it shouldn't be

// BEST (IMO):

  void DeleteFile(enum{Recursive, NonRecursive} option);
  DeleteFile(Recursive); // clear, quick to type, not reusable outside of
DeleteFile, cannot conflict with other type names
  // if there is another enum or variable with the same name, the function
enum value takes precedence



Soo, what do you think?

In my opinion this could make it much easier to design understandable
interfaces. I find myself often writing code like the above mentioned
"DeleteFile" thinking "an enum would make this much clearer", but then not
doing it because mostly all those additional enums are going to clutter the
rest of the API (and sometimes conflict with other stuff where I would like
to use the same name, but not the complete same enum).




--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">Hi guys<br><br>I'm not a compiler writer or have any exper=
ience designing languages, I am basically just an ordinary C++ user. So thi=
s proposal might not be up to the detail you'd might expect. Anyways...<br>=
<br>The idea is to have "local enums" in function calls as syntactic sugar,=
=20
so that it becomes easier to write clear interfaces in C++, something=20
that good programmers already do, but which often involves a lot of=20
extra typing and cluttering the namespace with lots and lots of=20
additional enums, that have no use outside of that one function.
<br><br>Here is the general concept:<br><br><div class=3D"prettyprint" styl=
e=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187)=
; border-style: solid; border-width: 1px; word-wrap: break-word;"><code cla=
ss=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by=
-prettify">Func1</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">enu=
m</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span styl=
e=3D"color: #606;" class=3D"styled-by-prettify">DoFoo</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" clas=
s=3D"styled-by-prettify">DoBar</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify=
">Param1</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #800;" class=3D"styled-by-prettify">// Param1 is just an=
 int, the enum is syntactic sugar</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>&nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">if</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span=
><span style=3D"color: #606;" class=3D"styled-by-prettify">Param</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D=3D</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #6=
06;" class=3D"styled-by-prettify">DoFoo</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br>&nbsp; </span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">...</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color: =
#008;" class=3D"styled-by-prettify">void</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D=
"styled-by-prettify">Func2</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Param1</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">...</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #800;" class=3D"styled-by-prettify">// inval=
id, same type</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br><br></span><span style=3D"color: #606;" class=3D"styled-by-prettify"=
>Func1</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</s=
pan><span style=3D"color: #606;" class=3D"styled-by-prettify">DoFoo</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #800;" class=3D"styled-by-prettify">// compiler knows that Param1 is an=
 enum in the scope of Func1, substitutes DoFoo with 0</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color:=
 #606;" class=3D"styled-by-prettify">Func1</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">(</span><span style=3D"color: #066;" class=
=3D"styled-by-prettify">0</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify">//=
 same as DoFoo</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br></span><span style=3D"color: #606;" class=3D"styled-by-prettify">Fu=
nc1</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span=
><span style=3D"color: #066;" class=3D"styled-by-prettify">1</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #80=
0;" class=3D"styled-by-prettify">// same as DoBar</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color:=
 #008;" class=3D"styled-by-prettify">enum</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">{</span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">DidFoo</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify=
">DidBar</span><span style=3D"color: #660;" class=3D"styled-by-prettify">}<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #606;" class=3D"styled-by-prettify">Func3</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">()</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #80=
0;" class=3D"styled-by-prettify">// again, return value is just an int</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; </span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">return</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
606;" class=3D"styled-by-prettify">DidFoo</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"style=
d-by-prettify">// just returns 0</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br><br></span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">if</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><s=
pan style=3D"color: #606;" class=3D"styled-by-prettify">Func3</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">()</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">=3D=3D</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D=
"styled-by-prettify">Func3</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">::</span><span style=3D"color: #606;" class=3D"styled-by-pr=
ettify">DidFoo</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">...</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #800;" class=3D"styled-by-prettify">// for the return value, Fun=
c3 acts like an 'enum class'</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br><br><br></span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">void</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prett=
ify">Func4</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">enum</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"c=
olor: #606;" class=3D"styled-by-prettify">DoFoo</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-b=
y-prettify">0</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #606;" class=3D"styled-by-prettify">DoBar</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;=
" class=3D"styled-by-prettify">1</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-pret=
tify">Param1</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">enum</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #=
606;" class=3D"styled-by-prettify">DoFoo</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-prett=
ify">2</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #606;" class=3D"styled-by-prettify">DoBar</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=
=3D"styled-by-prettify">3</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Par=
am2</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #800;" class=3D"styled-by-prettify">// compiler error, DoFoo =
and DoBar may only be defined once across all parameters</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br>&nbsp; </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">if</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">(</span><span style=3D"color: #606;" class=3D"styled-by-pre=
ttify">Param1</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=3D=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #606;" class=3D"styled-by-prettify">DoFoo</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #80=
0;" class=3D"styled-by-prettify">// which one? -&gt; therefore not allowed<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">...</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br><br></span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">enum</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">{</span><span style=3D"color: #606;" class=3D"sty=
led-by-prettify">DidFoo</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">DidBa=
r</span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #606;" class=3D"styled-by-prettify">Func4</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">enum</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">{</span><span style=3D"color: #606;" class=3D"styled-by-=
prettify">DoFoo</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #066;" class=3D"styled-by-prettify">0</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" =
class=3D"styled-by-prettify">DoBar</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">1=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">Param1</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br>&nbsp; </span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">return</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-pre=
ttify">Param1</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #800;" class=3D"styled-by-prettify">// implicitely =
casts to the return 'type' (int), so this would return 0 or 1</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; </span><span =
style=3D"color: #800;" class=3D"styled-by-prettify">// well, actually both =
the return type and Param1 are alread int, so no real cast is done</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br><br></span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> ret </span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-b=
y-prettify">Func4</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">(</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Do=
Foo</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #800;" class=3D"styled-by-prettify">/* 0 */</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"c=
olor: #800;" class=3D"styled-by-prettify">// ret is of type int</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #800;" class=3D"styled-by-prettify">// you can either compare it=
 with 0, 1, etc. or with the 'enum values' Func4::DidFoo and Func4::DidBar<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></s=
pan><span style=3D"color: #800;" class=3D"styled-by-prettify">// outside of=
 the function call parenthesis, Func4::DoFoo and Func4::DoBar do not exist!=
 (this is THE crucial feature)</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br><br></span><span style=3D"color: #606;" class=3D"st=
yled-by-prettify">Func1</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">(</span><span style=3D"color: #606;" class=3D"styled-by-pretti=
fy">Func4</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:=
:</span><span style=3D"color: #606;" class=3D"styled-by-prettify">DoFoo</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> &nbsp;</span><span st=
yle=3D"color: #800;" class=3D"styled-by-prettify">// compiler error, 'Func4=
::DoFoo' unknown type</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br></span><span style=3D"color: #606;" class=3D"styled-by-prett=
ify">Func1</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
(</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Func4</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span=
 style=3D"color: #606;" class=3D"styled-by-prettify">DidFoo</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800=
;" class=3D"styled-by-prettify">// probably ok, the return enum type of Fun=
c4 needs to be globally accessible</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br><br></span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">// actually for the return type one could just leav=
e this feature out, and say one has to create a real enum for this, since i=
t would need to be globally accessible</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br></span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">// but for consistency it would probably be nice to=
 have it still</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br><br><br></span><span style=3D"color: #800;" class=3D"styled-by-pret=
tify">// Reasoning:</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br><br></span><span style=3D"color: #800;" class=3D"styled-by-pre=
ttify">// BAD:</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br><br>&nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">void</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Delete=
File</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">bool</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> bRecursive</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; </span><span styl=
e=3D"color: #606;" class=3D"styled-by-prettify">DeleteFile</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">false</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"sty=
led-by-prettify">// um, what?</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br><br></span><span style=3D"color: #800;" class=3D"sty=
led-by-prettify">// BETTER:</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br><br>&nbsp; </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">enum</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-p=
rettify">DeleteFileOptions</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #606;" class=3D"styled-by-prettify">Recursive</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">NonRecursive</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">};</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br>&nbsp; </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">void</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"st=
yled-by-prettify">DeleteFile</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">(</span><span style=3D"color: #606;" class=3D"styled-by-p=
rettify">DeleteFileOptions</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> option</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br>&nbsp; </span><span style=3D"color: #606;" class=3D"styled-by-pret=
tify">DeleteFile</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">(</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Rec=
ursive</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #800;" class=3D"styled-by-prettify">// ah!,</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; </span><span =
style=3D"color: #800;" class=3D"styled-by-prettify">// but so much typing, =
also DeleteFileOptions is now globally accessible and can</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; </span><span styl=
e=3D"color: #800;" class=3D"styled-by-prettify">// a) conflict with other s=
tuff and</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r>&nbsp; </span><span style=3D"color: #800;" class=3D"styled-by-prettify">/=
/ b) reused where it shouldn't be</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br><br></span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">// BEST (IMO):</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br><br>&nbsp; </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">void</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"st=
yled-by-prettify">DeleteFile</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">enum</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">{</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Recurs=
ive</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #606;" class=3D"styled-by-prettify">NonRecursive</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> option</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br>&nbsp; </span><span style=3D"color: #60=
6;" class=3D"styled-by-prettify">DeleteFile</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">(</span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">Recursive</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-pre=
ttify">// clear, quick to type, not reusable outside of DeleteFile, cannot =
conflict with other type names</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br>&nbsp; </span><span style=3D"color: #800;" class=3D=
"styled-by-prettify">// if there is another enum or variable with the same =
name, the function enum value takes precedence</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"><br><br></span></div></code></div><br><=
br>

Soo, what do you think?<br><br>In my opinion this could make it much easier=
 to design understandable interfaces. I find myself often writing code like=
 the above mentioned "DeleteFile" thinking "an enum would make this much cl=
earer", but then not doing it because mostly all those additional enums are=
 going to clutter the rest of the API (and sometimes conflict with other st=
uff where I would like to use the same name, but not the complete same enum=
).<br><br><br><br><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_597_33539223.1402427523643--

.

On 10 June 2014 22:12,  <jan.krassnigg@gmail.com> wrote:
> Hi guys
>
> I'm not a compiler writer or have any experience designing languages, I am
> basically just an ordinary C++ user. So this proposal might not be up to the
> detail you'd might expect. Anyways...
>
> The idea is to have "local enums" in function calls as syntactic sugar, so
> that it becomes easier to write clear interfaces in C++, something that good
> programmers already do, but which often involves a lot of extra typing and
> cluttering the namespace with lots and lots of additional enums, that have
> no use outside of that one function.


1) Why don't you place the enums and the functions inside a namespace?
2) Why don't you place the enums and the functions inside a class?

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

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

I think there might be something in this.  Perhaps a generalization of your
idea is to introduce the notion of a function name scope.  Names can be
introduced into the function name scope of a function F by syntax in the
declarations of the function F.  A name N in function name scope can be
looked up with qualified lookup on the function name F::N, or unqualified
from within the function definition of F.  This would allow you to
introduce entities that are specific to a function (for a specific example
an enumeration used by one of its parameters or return value).





On Tue, Jun 10, 2014 at 9:12 PM, <jan.krassnigg@gmail.com> wrote:

> Hi guys
>
> I'm not a compiler writer or have any experience designing languages, I am
> basically just an ordinary C++ user. So this proposal might not be up to
> the detail you'd might expect. Anyways...
>
> The idea is to have "local enums" in function calls as syntactic sugar, so
> that it becomes easier to write clear interfaces in C++, something that
> good programmers already do, but which often involves a lot of extra typing
> and cluttering the namespace with lots and lots of additional enums, that
> have no use outside of that one function.
>
> Here is the general concept:
>
>
> void Func1(enum {DoFoo, DoBar} Param1) // Param1 is just an int, the enum
> is syntactic sugar
> {
>   if (Param == DoFoo)
>   { ... }
> }
>
> void Func2(int Param1) { ... } // invalid, same type
>
> Func1(DoFoo); // compiler knows that Param1 is an enum in the scope of
> Func1, substitutes DoFoo with 0
> Func1(0); // same as DoFoo
> Func1(1); // same as DoBar
>
> enum{DidFoo, DidBar} Func3() // again, return value is just an int
> {
>   return DidFoo; // just returns 0
> }
>
> if (Func3() == Func3::DidFoo) ... // for the return value, Func3 acts
> like an 'enum class'
>
>
> void Func4(enum {DoFoo = 0, DoBar = 1} Param1, enum {DoFoo = 2, DoBar = 3}
> Param2) // compiler error, DoFoo and DoBar may only be defined once
> across all parameters
> {
>   if (Param1 == DoFoo) // which one? -> therefore not allowed
>   ...
> }
>
> enum {DidFoo, DidBar} Func4(enum {DoFoo = 0, DoBar = 1} Param1)
> {
>   return Param1; // implicitely casts to the return 'type' (int), so this
> would return 0 or 1
>   // well, actually both the return type and Param1 are alread int, so no
> real cast is done
> }
>
> auto ret = Func4(DoFoo /* 0 */);
> // ret is of type int
> // you can either compare it with 0, 1, etc. or with the 'enum values'
> Func4::DidFoo and Func4::DidBar
>
> // outside of the function call parenthesis, Func4::DoFoo and Func4::DoBar
> do not exist! (this is THE crucial feature)
>
> Func1(Func4::DoFoo);  // compiler error, 'Func4::DoFoo' unknown type
> Func1(Func4::DidFoo); // probably ok, the return enum type of Func4 needs
> to be globally accessible
>
> // actually for the return type one could just leave this feature out, and
> say one has to create a real enum for this, since it would need to be
> globally accessible
> // but for consistency it would probably be nice to have it still
>
>
> // Reasoning:
>
> // BAD:
>
>   void DeleteFile(bool bRecursive);
>   DeleteFile(false); // um, what?
>
> // BETTER:
>
>   enum DeleteFileOptions { Recursive, NonRecursive };
>   void DeleteFile(DeleteFileOptions option);
>   DeleteFile(Recursive); // ah!,
>   // but so much typing, also DeleteFileOptions is now globally
> accessible and can
>   // a) conflict with other stuff and
>   // b) reused where it shouldn't be
>
> // BEST (IMO):
>
>   void DeleteFile(enum{Recursive, NonRecursive} option);
>   DeleteFile(Recursive); // clear, quick to type, not reusable outside of
> DeleteFile, cannot conflict with other type names
>   // if there is another enum or variable with the same name, the
> function enum value takes precedence
>
>
>
> Soo, what do you think?
>
> In my opinion this could make it much easier to design understandable
> interfaces. I find myself often writing code like the above mentioned
> "DeleteFile" thinking "an enum would make this much clearer", but then not
> doing it because mostly all those additional enums are going to clutter the
> rest of the API (and sometimes conflict with other stuff where I would like
> to use the same name, but not the complete same enum).
>
>
>
>
>  --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">I think there might be something in this. =C2=A0Perhaps a =
generalization of your idea is to introduce the notion of a function name s=
cope. =C2=A0Names can be introduced into the function name scope of a funct=
ion F by syntax in the declarations of the function F. =C2=A0A name N in fu=
nction name scope can be looked up with qualified lookup on the function na=
me F::N, or unqualified from within the function definition of F. =C2=A0Thi=
s would allow you to introduce entities that are specific to a function (fo=
r a specific example an enumeration used by one of its parameters or return=
 value).<div>
<br><div><br></div><div><br></div></div></div><div class=3D"gmail_extra"><b=
r><br><div class=3D"gmail_quote">On Tue, Jun 10, 2014 at 9:12 PM,  <span di=
r=3D"ltr">&lt;<a href=3D"mailto:jan.krassnigg@gmail.com" target=3D"_blank">=
jan.krassnigg@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hi guys<br><br>I&#39;m not =
a compiler writer or have any experience designing languages, I am basicall=
y just an ordinary C++ user. So this proposal might not be up to the detail=
 you&#39;d might expect. Anyways...<br>
<br>The idea is to have &quot;local enums&quot; in function calls as syntac=
tic sugar,=20
so that it becomes easier to write clear interfaces in C++, something=20
that good programmers already do, but which often involves a lot of=20
extra typing and cluttering the namespace with lots and lots of=20
additional enums, that have no use outside of that one function.
<br><br>Here is the general concept:<br><br><div style=3D"background-color:=
rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;border-wi=
dth:1px;word-wrap:break-word"><code><div><span style=3D"color:#000"><br></s=
pan><span style=3D"color:#008">void</span><span style=3D"color:#000"> </spa=
n><span style=3D"color:#606">Func1</span><span style=3D"color:#660">(</span=
><span style=3D"color:#008">enum</span><span style=3D"color:#000"> </span><=
span style=3D"color:#660">{</span><span style=3D"color:#606">DoFoo</span><s=
pan style=3D"color:#660">,</span><span style=3D"color:#000"> </span><span s=
tyle=3D"color:#606">DoBar</span><span style=3D"color:#660">}</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#606">Param1</span><span st=
yle=3D"color:#660">)</span><span style=3D"color:#000"> </span><span style=
=3D"color:#800">// Param1 is just an int, the enum is syntactic sugar</span=
><span style=3D"color:#000"><br>
</span><span style=3D"color:#660">{</span><span style=3D"color:#000"><br>=
=C2=A0 </span><span style=3D"color:#008">if</span><span style=3D"color:#000=
"> </span><span style=3D"color:#660">(</span><span style=3D"color:#606">Par=
am</span><span style=3D"color:#000"> </span><span style=3D"color:#660">=3D=
=3D</span><span style=3D"color:#000"> </span><span style=3D"color:#606">DoF=
oo</span><span style=3D"color:#660">)</span><span style=3D"color:#000"><br>
=C2=A0 </span><span style=3D"color:#660">{</span><span style=3D"color:#000"=
> </span><span style=3D"color:#660">...</span><span style=3D"color:#000"> <=
/span><span style=3D"color:#660">}</span><span style=3D"color:#000"><br></s=
pan><span style=3D"color:#660">}</span><span style=3D"color:#000"><br>
<br></span><span style=3D"color:#008">void</span><span style=3D"color:#000"=
> </span><span style=3D"color:#606">Func2</span><span style=3D"color:#660">=
(</span><span style=3D"color:#008">int</span><span style=3D"color:#000"> </=
span><span style=3D"color:#606">Param1</span><span style=3D"color:#660">)</=
span><span style=3D"color:#000"> </span><span style=3D"color:#660">{</span>=
<span style=3D"color:#000"> </span><span style=3D"color:#660">...</span><sp=
an style=3D"color:#000"> </span><span style=3D"color:#660">}</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#800">// invalid, same type=
</span><span style=3D"color:#000"><br>
<br></span><span style=3D"color:#606">Func1</span><span style=3D"color:#660=
">(</span><span style=3D"color:#606">DoFoo</span><span style=3D"color:#660"=
>);</span><span style=3D"color:#000"> </span><span style=3D"color:#800">// =
compiler knows that Param1 is an enum in the scope of Func1, substitutes Do=
Foo with 0</span><span style=3D"color:#000"><br>
</span><span style=3D"color:#606">Func1</span><span style=3D"color:#660">(<=
/span><span style=3D"color:#066">0</span><span style=3D"color:#660">);</spa=
n><span style=3D"color:#000"> </span><span style=3D"color:#800">// same as =
DoFoo</span><span style=3D"color:#000"><br>
</span><span style=3D"color:#606">Func1</span><span style=3D"color:#660">(<=
/span><span style=3D"color:#066">1</span><span style=3D"color:#660">);</spa=
n><span style=3D"color:#000"> </span><span style=3D"color:#800">// same as =
DoBar</span><span style=3D"color:#000"><br>
<br></span><span style=3D"color:#008">enum</span><span style=3D"color:#660"=
>{</span><span style=3D"color:#606">DidFoo</span><span style=3D"color:#660"=
>,</span><span style=3D"color:#000"> </span><span style=3D"color:#606">DidB=
ar</span><span style=3D"color:#660">}</span><span style=3D"color:#000"> </s=
pan><span style=3D"color:#606">Func3</span><span style=3D"color:#660">()</s=
pan><span style=3D"color:#000"> </span><span style=3D"color:#800">// again,=
 return value is just an int</span><span style=3D"color:#000"><br>
</span><span style=3D"color:#660">{</span><span style=3D"color:#000"><br>=
=C2=A0 </span><span style=3D"color:#008">return</span><span style=3D"color:=
#000"> </span><span style=3D"color:#606">DidFoo</span><span style=3D"color:=
#660">;</span><span style=3D"color:#000"> </span><span style=3D"color:#800"=
>// just returns 0</span><span style=3D"color:#000"><br>
</span><span style=3D"color:#660">}</span><span style=3D"color:#000"><br><b=
r></span><span style=3D"color:#008">if</span><span style=3D"color:#000"> </=
span><span style=3D"color:#660">(</span><span style=3D"color:#606">Func3</s=
pan><span style=3D"color:#660">()</span><span style=3D"color:#000"> </span>=
<span style=3D"color:#660">=3D=3D</span><span style=3D"color:#000"> </span>=
<span style=3D"color:#606">Func3</span><span style=3D"color:#660">::</span>=
<span style=3D"color:#606">DidFoo</span><span style=3D"color:#660">)</span>=
<span style=3D"color:#000"> </span><span style=3D"color:#660">...</span><sp=
an style=3D"color:#000"> </span><span style=3D"color:#800">// for the retur=
n value, Func3 acts like an &#39;enum class&#39;</span><span style=3D"color=
:#000"><br>
<br><br></span><span style=3D"color:#008">void</span><span style=3D"color:#=
000"> </span><span style=3D"color:#606">Func4</span><span style=3D"color:#6=
60">(</span><span style=3D"color:#008">enum</span><span style=3D"color:#000=
"> </span><span style=3D"color:#660">{</span><span style=3D"color:#606">DoF=
oo</span><span style=3D"color:#000"> </span><span style=3D"color:#660">=3D<=
/span><span style=3D"color:#000"> </span><span style=3D"color:#066">0</span=
><span style=3D"color:#660">,</span><span style=3D"color:#000"> </span><spa=
n style=3D"color:#606">DoBar</span><span style=3D"color:#000"> </span><span=
 style=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><span st=
yle=3D"color:#066">1</span><span style=3D"color:#660">}</span><span style=
=3D"color:#000"> </span><span style=3D"color:#606">Param1</span><span style=
=3D"color:#660">,</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#008">enum</span><span style=3D"color:#000"> </span><span style=3D"col=
or:#660">{</span><span style=3D"color:#606">DoFoo</span><span style=3D"colo=
r:#000"> </span><span style=3D"color:#660">=3D</span><span style=3D"color:#=
000"> </span><span style=3D"color:#066">2</span><span style=3D"color:#660">=
,</span><span style=3D"color:#000"> </span><span style=3D"color:#606">DoBar=
</span><span style=3D"color:#000"> </span><span style=3D"color:#660">=3D</s=
pan><span style=3D"color:#000"> </span><span style=3D"color:#066">3</span><=
span style=3D"color:#660">}</span><span style=3D"color:#000"> </span><span =
style=3D"color:#606">Param2</span><span style=3D"color:#660">)</span><span =
style=3D"color:#000"> </span><span style=3D"color:#800">// compiler error, =
DoFoo and DoBar may only be defined once across all parameters</span><span =
style=3D"color:#000"><br>
</span><span style=3D"color:#660">{</span><span style=3D"color:#000"><br>=
=C2=A0 </span><span style=3D"color:#008">if</span><span style=3D"color:#000=
"> </span><span style=3D"color:#660">(</span><span style=3D"color:#606">Par=
am1</span><span style=3D"color:#000"> </span><span style=3D"color:#660">=3D=
=3D</span><span style=3D"color:#000"> </span><span style=3D"color:#606">DoF=
oo</span><span style=3D"color:#660">)</span><span style=3D"color:#000"> </s=
pan><span style=3D"color:#800">// which one? -&gt; therefore not allowed</s=
pan><span style=3D"color:#000"><br>
=C2=A0 </span><span style=3D"color:#660">...</span><span style=3D"color:#00=
0"><br></span><span style=3D"color:#660">}</span><span style=3D"color:#000"=
><br><br></span><span style=3D"color:#008">enum</span><span style=3D"color:=
#000"> </span><span style=3D"color:#660">{</span><span style=3D"color:#606"=
>DidFoo</span><span style=3D"color:#660">,</span><span style=3D"color:#000"=
> </span><span style=3D"color:#606">DidBar</span><span style=3D"color:#660"=
>}</span><span style=3D"color:#000"> </span><span style=3D"color:#606">Func=
4</span><span style=3D"color:#660">(</span><span style=3D"color:#008">enum<=
/span><span style=3D"color:#000"> </span><span style=3D"color:#660">{</span=
><span style=3D"color:#606">DoFoo</span><span style=3D"color:#000"> </span>=
<span style=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><sp=
an style=3D"color:#066">0</span><span style=3D"color:#660">,</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#606">DoBar</span><span sty=
le=3D"color:#000"> </span><span style=3D"color:#660">=3D</span><span style=
=3D"color:#000"> </span><span style=3D"color:#066">1</span><span style=3D"c=
olor:#660">}</span><span style=3D"color:#000"> </span><span style=3D"color:=
#606">Param1</span><span style=3D"color:#660">)</span><span style=3D"color:=
#000"><br>
</span><span style=3D"color:#660">{</span><span style=3D"color:#000"><br>=
=C2=A0 </span><span style=3D"color:#008">return</span><span style=3D"color:=
#000"> </span><span style=3D"color:#606">Param1</span><span style=3D"color:=
#660">;</span><span style=3D"color:#000"> </span><span style=3D"color:#800"=
>// implicitely casts to the return &#39;type&#39; (int), so this would ret=
urn 0 or 1</span><span style=3D"color:#000"><br>
=C2=A0 </span><span style=3D"color:#800">// well, actually both the return =
type and Param1 are alread int, so no real cast is done</span><span style=
=3D"color:#000"><br></span><span style=3D"color:#660">}</span><span style=
=3D"color:#000"><br>
<br></span><span style=3D"color:#008">auto</span><span style=3D"color:#000"=
> ret </span><span style=3D"color:#660">=3D</span><span style=3D"color:#000=
"> </span><span style=3D"color:#606">Func4</span><span style=3D"color:#660"=
>(</span><span style=3D"color:#606">DoFoo</span><span style=3D"color:#000">=
 </span><span style=3D"color:#800">/* 0 */</span><span style=3D"color:#660"=
>);</span><span style=3D"color:#000"><br>
</span><span style=3D"color:#800">// ret is of type int</span><span style=
=3D"color:#000"><br></span><span style=3D"color:#800">// you can either com=
pare it with 0, 1, etc. or with the &#39;enum values&#39; Func4::DidFoo and=
 Func4::DidBar</span><span style=3D"color:#000"><br>
<br></span><span style=3D"color:#800">// outside of the function call paren=
thesis, Func4::DoFoo and Func4::DoBar do not exist! (this is THE crucial fe=
ature)</span><span style=3D"color:#000"><br><br></span><span style=3D"color=
:#606">Func1</span><span style=3D"color:#660">(</span><span style=3D"color:=
#606">Func4</span><span style=3D"color:#660">::</span><span style=3D"color:=
#606">DoFoo</span><span style=3D"color:#660">);</span><span style=3D"color:=
#000"> =C2=A0</span><span style=3D"color:#800">// compiler error, &#39;Func=
4::DoFoo&#39; unknown type</span><span style=3D"color:#000"><br>
</span><span style=3D"color:#606">Func1</span><span style=3D"color:#660">(<=
/span><span style=3D"color:#606">Func4</span><span style=3D"color:#660">::<=
/span><span style=3D"color:#606">DidFoo</span><span style=3D"color:#660">);=
</span><span style=3D"color:#000"> </span><span style=3D"color:#800">// pro=
bably ok, the return enum type of Func4 needs to be globally accessible</sp=
an><span style=3D"color:#000"><br>
<br></span><span style=3D"color:#800">// actually for the return type one c=
ould just leave this feature out, and say one has to create a real enum for=
 this, since it would need to be globally accessible</span><span style=3D"c=
olor:#000"><br>
</span><span style=3D"color:#800">// but for consistency it would probably =
be nice to have it still</span><span style=3D"color:#000"><br><br><br></spa=
n><span style=3D"color:#800">// Reasoning:</span><span style=3D"color:#000"=
><br>
<br></span><span style=3D"color:#800">// BAD:</span><span style=3D"color:#0=
00"><br><br>=C2=A0 </span><span style=3D"color:#008">void</span><span style=
=3D"color:#000"> </span><span style=3D"color:#606">DeleteFile</span><span s=
tyle=3D"color:#660">(</span><span style=3D"color:#008">bool</span><span sty=
le=3D"color:#000"> bRecursive</span><span style=3D"color:#660">);</span><sp=
an style=3D"color:#000"><br>
=C2=A0 </span><span style=3D"color:#606">DeleteFile</span><span style=3D"co=
lor:#660">(</span><span style=3D"color:#008">false</span><span style=3D"col=
or:#660">);</span><span style=3D"color:#000"> </span><span style=3D"color:#=
800">// um, what?</span><span style=3D"color:#000"><br>
<br></span><span style=3D"color:#800">// BETTER:</span><span style=3D"color=
:#000"><br><br>=C2=A0 </span><span style=3D"color:#008">enum</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#606">DeleteFileOptions</sp=
an><span style=3D"color:#000"> </span><span style=3D"color:#660">{</span><s=
pan style=3D"color:#000"> </span><span style=3D"color:#606">Recursive</span=
><span style=3D"color:#660">,</span><span style=3D"color:#000"> </span><spa=
n style=3D"color:#606">NonRecursive</span><span style=3D"color:#000"> </spa=
n><span style=3D"color:#660">};</span><span style=3D"color:#000"><br>
=C2=A0 </span><span style=3D"color:#008">void</span><span style=3D"color:#0=
00"> </span><span style=3D"color:#606">DeleteFile</span><span style=3D"colo=
r:#660">(</span><span style=3D"color:#606">DeleteFileOptions</span><span st=
yle=3D"color:#000"> option</span><span style=3D"color:#660">);</span><span =
style=3D"color:#000"><br>
=C2=A0 </span><span style=3D"color:#606">DeleteFile</span><span style=3D"co=
lor:#660">(</span><span style=3D"color:#606">Recursive</span><span style=3D=
"color:#660">);</span><span style=3D"color:#000"> </span><span style=3D"col=
or:#800">// ah!,</span><span style=3D"color:#000"><br>
=C2=A0 </span><span style=3D"color:#800">// but so much typing, also Delete=
FileOptions is now globally accessible and can</span><span style=3D"color:#=
000"><br>=C2=A0 </span><span style=3D"color:#800">// a) conflict with other=
 stuff and</span><span style=3D"color:#000"><br>
=C2=A0 </span><span style=3D"color:#800">// b) reused where it shouldn&#39;=
t be</span><span style=3D"color:#000"><br><br></span><span style=3D"color:#=
800">// BEST (IMO):</span><span style=3D"color:#000"><br><br>=C2=A0 </span>=
<span style=3D"color:#008">void</span><span style=3D"color:#000"> </span><s=
pan style=3D"color:#606">DeleteFile</span><span style=3D"color:#660">(</spa=
n><span style=3D"color:#008">enum</span><span style=3D"color:#660">{</span>=
<span style=3D"color:#606">Recursive</span><span style=3D"color:#660">,</sp=
an><span style=3D"color:#000"> </span><span style=3D"color:#606">NonRecursi=
ve</span><span style=3D"color:#660">}</span><span style=3D"color:#000"> opt=
ion</span><span style=3D"color:#660">);</span><span style=3D"color:#000"><b=
r>
=C2=A0 </span><span style=3D"color:#606">DeleteFile</span><span style=3D"co=
lor:#660">(</span><span style=3D"color:#606">Recursive</span><span style=3D=
"color:#660">);</span><span style=3D"color:#000"> </span><span style=3D"col=
or:#800">// clear, quick to type, not reusable outside of DeleteFile, canno=
t conflict with other type names</span><span style=3D"color:#000"><br>
=C2=A0 </span><span style=3D"color:#800">// if there is another enum or var=
iable with the same name, the function enum value takes precedence</span><s=
pan style=3D"color:#000"><br><br></span></div></code></div><br><br>

Soo, what do you think?<br><br>In my opinion this could make it much easier=
 to design understandable interfaces. I find myself often writing code like=
 the above mentioned &quot;DeleteFile&quot; thinking &quot;an enum would ma=
ke this much clearer&quot;, but then not doing it because mostly all those =
additional enums are going to clutter the rest of the API (and sometimes co=
nflict with other stuff where I would like to use the same name, but not th=
e complete same enum).<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br><br><br><br></font></span></div><span class=3D"HOEnZb"><font color=3D"#=
888888">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--bcaec50e5ea523ff4504fb806762--

.

------=_Part_3339_18103865.1402431483603
Content-Type: text/plain; charset=UTF-8


>
> 1) Why don't you place the enums and the functions inside a namespace?
> 2) Why don't you place the enums and the functions inside a class?
>
>
Oh, I already do that. But many functions would benefit from having better
names for their options and for that you would use an enum. This enum is
specific to ONE SINGLE function. Thus declaring extra enums outside the
functions will always clutter some namespace.

Just have a look at Qt. It generally does this very well by using enums for
everything to have a well documented interface, but the Qt namespace is
therefore very cluttered with enum types that are not really used in many
places.

Given my example above, would you really put the "DeleteFile" function in
its own namespace or class? I don't think so. You might want to group a set
of related functions (e.g. all functions for file accesses) into its own
namespace, but then you would clutter THAT namespace with enums.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-lef=
t: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote">=
1) Why don't you place the enums and the functions inside a namespace?
<br>2) Why don't you place the enums and the functions inside a class?
<br><br></blockquote><div dir=3D"ltr"><br>Oh, I already do that. But many f=
unctions would benefit from having better names for their options and for t=
hat you would use an enum. This enum is specific to ONE SINGLE function. Th=
us declaring extra enums outside the functions will always clutter some nam=
espace.<br><br>Just have a look at Qt. It generally does this very well by =
using enums for everything to have a well documented interface, but the Qt =
namespace is therefore very cluttered with enum types that are not really u=
sed in many places.<br><br>Given my example above, would you really put the=
 "DeleteFile" function in its own namespace or class? I don't think so. You=
 might want to group a set of related functions (e.g. all functions for fil=
e accesses) into its own namespace, but then you would clutter THAT namespa=
ce with enums.<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_3339_18103865.1402431483603--

.

On 2014-06-10 15:12, jan.krassnigg@gmail.com wrote:
> // BEST (IMO):
>
>   void DeleteFile(enum{Recursive, NonRecursive} option);
>   DeleteFile(Recursive); // clear, quick to type, not reusable outside of
> DeleteFile, cannot conflict with other type names
>   // if there is another enum or variable with the same name, the function
> enum value takes precedence

  static struct DeleteFile
  {
    enum class Option
    {
      Recursive,
      ...
    };
    using enum Option;

    operator()(Option) {...}
  };

  auto mode = DeleteFiles::Recursive
  DeleteFiles(mode);

....? :-)

Now one can still name the option (which I don't think we should lose;
what if it needs to be set based on some logic apart from the call
site?), but in a way that is clear that it is associated with the
"function". (Admittedly the syntax at the declaration site is a bit more
verbose, and I used some constructs that don't exist yet.)

The decoration 'static' on a struct says that the struct is
non-constructable and that all members are static... basically a
namespace, except that it can have operators (in particular, an
operator()). (@Andrew, which makes it basically your 'function name
scope'.) The non-constructable seems necessary for 'T()' to
unambiguously mean a call rather than construction.

The other necessary change would be that qualified lookup in the context
of such operator() would consider the scope of the operator() as in
scope for the parameter list. This possibly has general application
(e.g. to any method call) and could be convenient in other places.

'using enum' has shown up before. It isn't strictly necessary, but is
massively convenient in order to be able to use a strongly typed enum.
(Note that this would disallow the conversions as specified in the
original post, although the parameter type would have to be non-enum to
allow those in either case.)

--
Matthew

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_311_29231589.1402434564962
Content-Type: text/plain; charset=UTF-8



> Do you think such enums are common enough for a core language change?
>

Yes I do, otherwise I wouldn't have posted the idea here. I see it very
regularly that people write interfaces with lots of bools to switch between
different options, were true/false is just not very informative about what
is going on.

Regarding the different ways shown how this is possible today (or soon).
All of them are quite complicated and a lot of typing. The whole point
about this proposal is that it should make it EASY to write better
interfaces. It is not about make it possible at all.

This is, as I already mentioned above, syntactic sugar.



--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><br><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border=
-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quo=
te">Do you think such enums are common enough for a core language change?
<br></blockquote><div><br>Yes I do, otherwise I wouldn't have posted the id=
ea here. I see it very regularly that people write interfaces with lots of =
bools to switch between different options, were true/false is just not very=
 informative about what is going on.<br><br>Regarding the different ways sh=
own how this is possible today (or soon). All of them are quite complicated=
 and a lot of typing. The whole point about this proposal is that it should=
 make it EASY to write better interfaces. It is not about make it possible =
at all.<br><br>This is, as I already mentioned above, syntactic sugar.<br><=
/div><div><br>&nbsp;</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_311_29231589.1402434564962--

.

On 2014-06-10 16:43, Richard Smith wrote:
> On Tue, Jun 10, 2014 at 1:38 PM, Johannes Schaub wrote:
>> 2014-06-10 22:34 GMT+02:00 Matthew Woehlke wrote:
>>>   static struct DeleteFile
>>>   {
>>>     enum class Option
>>>     {
>>>       Recursive,
>>>       ...
>>>     };
>>>     using enum Option;
>>>
>>>     operator()(Option) {...}
>>>   };
>>>
>>>   auto mode = DeleteFiles::Recursive
>>>   DeleteFiles(mode);
>>
>> This is a heavy change in interface and includes much boilerplate
>> code.

True. OTOH you can do all sorts of things with this (e.g. "function"
local types, static variables, etc.) that you couldn't do with the
original proposal. And the changes to the compiler are less; don't allow
construction, and treat 'T()' as invoking the operator() rather than
construction. (And 'using enum' and changes to scope lookup rules, but
the former is independently desirable, and the latter is required
regardless.) Compare to allowing definitions of enums inside of a
parameter list. (And how would you provide a separate definition of a
function given the original proposal? Specify that the enum *must* be
nameless and is considered a type specifier?)

And really, how much overhead is it? We have "static struct", "{",
"using", "Option", "operator()", and "};". The rest is there in the
original proposal as well. (Note: I assumed a further refinement to
allow "using" to apply to the definition of the enum.)

>> BTW, the code creates a default constructed "DeleteFiles"
>> variable called "mode".

Huh? How do you figure that? (Especially since DeleteFiles is not
constructable...)

'DeleteFiles::Recursive' names an enum value. Assigning to an auto
variable 'mode' declares 'mode' to be of the enum type with the named
value. I see no construction of the enclosing scope object.

> I assume this was meant to be
>
>   static struct DeleteFile { /* ... */ } <ins>DeleteFile</ins>;

Ah... no? In fact that wouldn't be legal. ("static struct" is maybe not
the best way to designate the scope. I picked it because it uses only
existing keywords, but I see where the compiler differentiating a
definition versus a declaration could be tricky. But that's mostly
bikeshedding.)

--
Matthew

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_651_19317979.1402441633976
Content-Type: text/plain; charset=UTF-8

On Tuesday, 10 June 2014 21:34:55 UTC+1, Matthew Woehlke wrote:

>   static struct DeleteFile
>   {
>     enum class Option
>     {
>       Recursive,
>       ...
>     };
>     using enum Option;
>
>     operator()(Option) {...}
>   };
>
>   auto mode = DeleteFiles::Recursive
>   DeleteFiles(mode);
>

One can already write

struct DeleteFiles {
  enum mode { Recursive };
  void operator()(mode);
} DeleteFiles;
DeleteFiles(DeleteFiles::Recursive);

I'm not clear what your proposal would enable.

If I understand the original proposal correctly, it is desired to be able
to write simply DeleteFiles(Recursive) and have name lookup of Recursive
take place within a scope associated with DeleteFiles. In essence it's the
complement or possibly inverse of argument-dependent lookup; it sounds like
a great idea but would require very careful writing of rules to ensure that
it doesn't conflict with ADL.

If this name lookup were to extend to types and variables (not just
enumerators) then that could be useful in other cases e.g. passing
piecewise_construct or allocator_arg, or even for Boost-style named
arguments.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On Tuesday, 10 June 2014 21:34:55 UTC+1, Matthew Woehlke  =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&nbsp; static struct=
 DeleteFile
<br>&nbsp; {
<br>&nbsp; &nbsp; enum class Option
<br>&nbsp; &nbsp; {
<br>&nbsp; &nbsp; &nbsp; Recursive,
<br>&nbsp; &nbsp; &nbsp; ...
<br>&nbsp; &nbsp; };
<br>&nbsp; &nbsp; using enum Option;
<br>
<br>&nbsp; &nbsp; operator()(Option) {...}
<br>&nbsp; };
<br>
<br>&nbsp; auto mode =3D DeleteFiles::Recursive
<br>&nbsp; DeleteFiles(mode);
<br></blockquote><div><br></div><div>One can already write</div><div><br></=
div><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250=
); border: 1px solid rgb(187, 187, 187); word-wrap: break-word;"><code clas=
s=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;=
" class=3D"styled-by-prettify">struct</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"st=
yled-by-prettify">DeleteFiles</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br>&nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">enum</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> mod=
e </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #606;" class=3D"styled-by-prettify">Recursive</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">};</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br>&nbsp; </span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">void</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">operator</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">()(</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify">mode</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">DeleteFiles</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #60=
6;" class=3D"styled-by-prettify">DeleteFiles</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">(</span><span style=3D"color: #606;" clas=
s=3D"styled-by-prettify">DeleteFiles</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">::</span><span style=3D"color: #606;" class=3D"st=
yled-by-prettify">Recursive</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br></span></div></code></div><div><br>I'm not clear what your pro=
posal would enable.</div><div><br></div><div>If I understand the original p=
roposal correctly, it is desired to be able to write simply <font face=3D"c=
ourier new, monospace">DeleteFiles(Recursive)</font> and have name lookup o=
f <font face=3D"courier new, monospace">Recursive</font> take place within =
a scope associated with <font face=3D"courier new, monospace">DeleteFiles</=
font>. In essence it's the complement or possibly inverse of argument-depen=
dent lookup; it sounds like a great idea but would require very careful wri=
ting of rules to ensure that it doesn't conflict with ADL.</div><div><br></=
div><div>If this name lookup were to extend to types and variables (not jus=
t enumerators) then that could be useful in other cases e.g. passing <font =
face=3D"courier new, monospace">piecewise_construct</font> or <font face=3D=
"courier new, monospace">allocator_arg</font>, or even for Boost-style name=
d arguments.</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_651_19317979.1402441633976--

.

On 2014-06-10 19:02, Richard Smith wrote:
> On Tue, Jun 10, 2014 at 2:29 PM, Matthew Woehlke <
> mw_triad@users.sourceforge.net> wrote:
>
>> On 2014-06-10 16:43, Richard Smith wrote:
>>> On Tue, Jun 10, 2014 at 1:38 PM, Johannes Schaub wrote:
>>>> 2014-06-10 22:34 GMT+02:00 Matthew Woehlke wrote:
>>>>>   static struct DeleteFile
>>>>>   {
>>>>>     enum class Option
>>>>>     {
>>>>>       Recursive,
>>>>>       ...
>>>>>     };
>>>>>     using enum Option;
>>>>>
>>>>>     operator()(Option) {...}
>>>>>   };
>>>>>
>>>>>   auto mode = DeleteFiles::Recursive
>>>>>   DeleteFiles(mode);
>>>>
>>>> This is a heavy change in interface and includes much boilerplate
>>>> code.
>>
>> True. OTOH you can do all sorts of things with this (e.g. "function"
>> local types, static variables, etc.) that you couldn't do with the
>> original proposal. And the changes to the compiler are less; don't allow
>> construction, and treat 'T()' as invoking the operator() rather than
>> construction. (And 'using enum' and changes to scope lookup rules, but
>> the former is independently desirable, and the latter is required
>> regardless.) Compare to allowing definitions of enums inside of a
>> parameter list. (And how would you provide a separate definition of a
>> function given the original proposal? Specify that the enum *must* be
>> nameless and is considered a type specifier?)
>>
>> And really, how much overhead is it? We have "static struct", "{",
>> "using", "Option", "operator()", and "};". The rest is there in the
>> original proposal as well. (Note: I assumed a further refinement to
>> allow "using" to apply to the definition of the enum.)
>>
>>>> BTW, the code creates a default constructed "DeleteFiles"
>>>> variable called "mode".
>>
>> Huh? How do you figure that? (Especially since DeleteFiles is not
>> constructable...)
>>
>> 'DeleteFiles::Recursive' names an enum value. Assigning to an auto
>> variable 'mode' declares 'mode' to be of the enum type with the named
>> value. I see no construction of the enclosing scope object.
>>
>>> I assume this was meant to be
>>>
>>>   static struct DeleteFile { /* ... */ } <ins>DeleteFile</ins>;
>>
>> Ah... no? In fact that wouldn't be legal.
>
> Huh? That is legal C++ already, and does exactly what you wanted, no?

Well... sort-of. Hmm, in fact, I guess you could do that, but that
wasn't what I was trying to do, which is to not have an allocated
object. (For that to be reasonable, you'd also want to make operator()
static so as to avoid having an unwanted 'this' in the body and
parameter list thereof.)

What I wrote, which *was* what I meant to write, is not currently legal.

Given a suitable annotation for a static struct, it *would* be illegal
to instantiate such a struct, which is what I meant. Alas, the
originally suggested syntax (which, as previously stated, is not ideal)
makes that ambiguous with a static instance of a regular struct.

--
Matthew

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2014-06-10 19:07, Edward Catmur wrote:
> On Tuesday, 10 June 2014 21:34:55 UTC+1, Matthew Woehlke wrote:
>
>>   static struct DeleteFile
>>   {
>>     enum class Option
>>     {
>>       Recursive,
>>       ...
>>     };
>>     using enum Option;
>>
>>     operator()(Option) {...}
>>   };
>>
>>   auto mode = DeleteFiles::Recursive
>>   DeleteFiles(mode);
>>
>
> One can already write
>
> struct DeleteFiles {
>   enum mode { Recursive };
>   void operator()(mode);
> } DeleteFiles;
> DeleteFiles(DeleteFiles::Recursive);
>
> I'm not clear what your proposal would enable.

The *type* DeleteFiles would not be instantiable. All members would be
implicitly static (without having to explicitly mark them thusly). One
could write 'DeleteFiles()' (remember, DeleteFiles here is a *type*, not
an instance) and it would invoke DeleteFiles::operator(), and not a
constructor. (Writing DeleteFiles{...} would be illegal, since that is
explicitly construction and not a call to operator(), and DeleteFiles
may not be instantiated.)

Essentially, DeleteFiles would act like a namespace rather than a
struct, except that it could have (static) operators; operator() in
particular, but others could be permitted.

> If I understand the original proposal correctly, it is desired to be able
> to write simply DeleteFiles(Recursive) and have name lookup of Recursive
> take place within a scope associated with DeleteFiles.

That's one part. Given a "static struct" (or even a static instance of a
struct), that part becomes the ADL change that you mentioned elsewhere.
(Which I also happen to think would be nice to have independent of the
other elements here.)

The other part is the ability to define members in the scope of
something that looks like a function. The static struct instance with
the same name as the type "works" for that purpose but is inelegant
(requires an extra object be instantiated, repeating the name,
decorating members as 'static' in addition to the instantiation)... and
is even more verbose than my proposal, which was already getting
complaints for that reason.

Another consideration that just occurred to me; probably we want this to
also work for member functions, which would be another reason to write
something more like 'function scope' than "static struct".
(Incidentally, this also means the suggested work-arounds with current
structs work much more poorly for this case.)

IOW:

class Foo
{
  function ping // or some other keyword/decorator
  {
    enum class type { HTTP, IGMP, ... };
    operator()(type t) {...}
  };
  static function pop {...}
};

In the above, 'ping()' would have to be called as a member function of a
Foo instance, and would have a 'this' which refers to that instance
(like a normal member function). Similarly, 'pop()' would behave like a
static member function.

> If this name lookup were to extend to types and variables (not just
> enumerators) then that could be useful in other cases e.g. passing
> piecewise_construct or allocator_arg, or even for Boost-style named
> arguments.

Um... too late now, but it would have been great to have this for
std::bind (for _1, _2, etc.). Maybe if the std::abi proposal goes
through we will have more "wiggle room" to make breaking changes :-).

--
Matthew

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_2024_1635806.1402523079457
Content-Type: text/plain; charset=UTF-8

On Tuesday, June 10, 2014 4:07:14 PM UTC-7, Edward Catmur wrote:
>
>
> One can already write
>
> struct DeleteFiles {
>   enum mode { Recursive };
>   void operator()(mode);
> } DeleteFiles;
> DeleteFiles(DeleteFiles::Recursive);
>
> I'm not clear what your proposal would enable.
>

That is not the same thing. That creates an object, allocates it some space
(which has to live somewhere; think of DLL/.so boundaries!), and includes
an entirely useless implicit `this` parameter to the operator() call.
That's a lot of extra runtime nonsense just to make a static interface
cleaner.

The real problem I see with the original proposal is that it
over-complicates defining a function separate from a declaration, since
presumably they both must match exactly in their enum declaration.

Also, how does it deal with functions that take a strict enumeration (A or
B) vs those that take flags (A and/or B) ? Do you allow both `enum` and
`enum class` (former allows bit operations, but also implicit conversions,
while the second allows neither) ?

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On Tuesday, June 10, 2014 4:07:14 PM UTC-7, Edward Catmur =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><b=
r></div><div>One can already write</div><div><br></div><div style=3D"backgr=
ound-color:rgb(250,250,250);border:1px solid rgb(187,187,187);word-wrap:bre=
ak-word"><code><div><span style=3D"color:#008">struct</span><span style=3D"=
color:#000"> </span><span style=3D"color:#606">DeleteFiles</span><span styl=
e=3D"color:#000"> </span><span style=3D"color:#660">{</span><span style=3D"=
color:#000"><br>&nbsp; </span><span style=3D"color:#008">enum</span><span s=
tyle=3D"color:#000"> mode </span><span style=3D"color:#660">{</span><span s=
tyle=3D"color:#000"> </span><span style=3D"color:#606">Recursive</span><spa=
n style=3D"color:#000"> </span><span style=3D"color:#660">};</span><span st=
yle=3D"color:#000"><br>&nbsp; </span><span style=3D"color:#008">void</span>=
<span style=3D"color:#000"> </span><span style=3D"color:#008">operator</spa=
n><span style=3D"color:#660">()(</span><span style=3D"color:#000">mode</spa=
n><span style=3D"color:#660">);</span><span style=3D"color:#000"><br></span=
><span style=3D"color:#660">}</span><span style=3D"color:#000"> </span><spa=
n style=3D"color:#606">DeleteFiles</span><span style=3D"color:#660">;</span=
><span style=3D"color:#000"><br></span><span style=3D"color:#606">DeleteFil=
es</span><span style=3D"color:#660">(</span><span style=3D"color:#606">Dele=
teFiles</span><span style=3D"color:#660">::</span><span style=3D"color:#606=
">Recur<wbr>sive</span><span style=3D"color:#660">);</span><span style=3D"c=
olor:#000"><br></span></div></code></div><div><br>I'm not clear what your p=
roposal would enable.</div></div></blockquote><div><br></div><div>That is n=
ot the same thing. That creates an object, allocates it some space (which h=
as to live somewhere; think of DLL/.so boundaries!), and includes an entire=
ly useless implicit `this` parameter to the operator() call. That's a lot o=
f extra runtime nonsense just to make a static interface cleaner.</div><div=
><br></div><div>The real problem I see with the original proposal is that i=
t over-complicates defining a function separate from a declaration, since p=
resumably they both must match exactly in their enum declaration.</div><div=
><br></div><div>Also, how does it deal with functions that take a strict en=
umeration (A or B) vs those that take flags (A and/or B) ? Do you allow bot=
h `enum` and `enum class` (former allows bit operations, but also implicit =
conversions, while the second allows neither) ?</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2024_1635806.1402523079457--

.

------=_Part_428_536085.1402524568240
Content-Type: text/plain; charset=UTF-8



> The real problem I see with the original proposal is that it
> over-complicates defining a function separate from a declaration, since
> presumably they both must match exactly in their enum declaration.
>
> Also, how does it deal with functions that take a strict enumeration (A or
> B) vs those that take flags (A and/or B) ? Do you allow both `enum` and
> `enum class` (former allows bit operations, but also implicit conversions,
> while the second allows neither) ?
>

Actually the way I envisioned it is that the parameter is simply always an
int, but that the enum part is like an "annotation" (or whatever you'd want
to call it).
Similar to a default value for a parameter.

So these two declarations would declare the same function:

void DeleteFile(int options);
void DeleteFile(enum{opt1, opt2} options);

The same way that

void foo(int p);
void foo(int p = 1);

declare the same function. Only that whatever the compiler could see would
be used at the call site to "enhance the user experience".

Thinking of this, one could also use an alternative syntax:

void DeleteFile(int options = enum{opt1, opt2});

Although you couldn't combine that with an actual default value, so that
might not be desirable.

You could however just use the full spectrum of enum features:

void DeleteFile(enum : short{flag1, flag2} options); // declares a
non-class enum with underlying type short that allows to combine the flags

void DeleteFile(enum class {option1, option2} options); // only option1 or
option2 can be passed along, they cannot be combined

When no underlying type is specified by hand, int should be assumed.


Even in the enum class case I would say that the underlying type specifies
the actual type of the function. So I could forward declare a function by
just using "int" and not caring about the details of the enum. Only when
the compiler sees a declaration that additionally specifies the enum
"annotation" for the int parameter, will it help the user by allowing to
type the enum values for the parameter (or in the enum class case, forcing
him).

This is similar to default values in that the default value does not change
the type of the function and could actually be declared differently in
different files. I would allow the same in this case.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><br><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border=
-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quo=
te"><div>The
 real problem I see with the original proposal is that it=20
over-complicates defining a function separate from a declaration, since=20
presumably they both must match exactly in their enum declaration.</div><di=
v><br></div><div>Also,
 how does it deal with functions that take a strict enumeration (A or B)
 vs those that take flags (A and/or B) ? Do you allow both `enum` and=20
`enum class` (former allows bit operations, but also implicit=20
conversions, while the second allows neither) ?</div></blockquote><div><br>=
Actually the way I envisioned it is that the parameter is simply always an =
int, but that the enum part is like an "annotation" (or whatever you'd want=
 to call it).<br>Similar to a default value for a parameter.<br><br>So thes=
e two declarations would declare the same function:<br><br>void DeleteFile(=
int options);<br>void DeleteFile(enum{opt1, opt2} options);<br><br>The same=
 way that<br><br>void foo(int p);<br>void foo(int p =3D 1);<br><br>declare =
the same function. Only that whatever the compiler could see would be used =
at the call site to "enhance the user experience".<br><br>Thinking of this,=
 one could also use an alternative syntax:<br><br>void DeleteFile(int optio=
ns =3D enum{opt1, opt2});<br><br>Although  you couldn't combine that with a=
n actual default value, so that might not be desirable.<br><br>You could ho=
wever just use the full spectrum of enum features:<br><br>void DeleteFile(e=
num : short{flag1, flag2} options); // declares a non-class enum with under=
lying type short that allows to combine the flags<br><br>void DeleteFile(en=
um class {option1, option2} options); // only option1 or option2 can be pas=
sed along, they cannot be combined<br><br>When no underlying type is specif=
ied by hand, int should be assumed.<br><br><br>Even in the enum class case =
I would say that the underlying type specifies the actual type of the funct=
ion. So I could forward declare a function by just using "int" and not cari=
ng about the details of the enum. Only when the compiler sees a declaration=
 that additionally specifies the enum "annotation" for the int parameter, w=
ill it help the user by allowing to type the enum values for the parameter =
(or in the enum class case, forcing him).<br><br>This is similar to default=
 values in that the default value does not change the type of the function =
and could actually be declared differently in different files. I would allo=
w the same in this case.<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_428_536085.1402524568240--

.

On 2014-06-11 18:09, jan.krassnigg@gmail.com wrote:
>> Also, how does it deal with functions that take a strict enumeration (A or
>> B) vs those that take flags (A and/or B) ? Do you allow both `enum` and
>> `enum class` (former allows bit operations, but also implicit conversions,
>> while the second allows neither) ?
>
> Actually the way I envisioned it is that the parameter is simply always an
> int, but that the enum part is like an "annotation" (or whatever you'd want
> to call it).
>
> Similar to a default value for a parameter.
>
> Thinking of this, one could also use an alternative syntax:
>
> void DeleteFile(int options = enum{opt1, opt2});

Please no. That to me is an egregious abuse of default parameter syntax
for something completely different. (Really, I don't see how parameter
value naming is in any way related to defaulted parameters.)

> Although you couldn't combine that with an actual default value, so that
> might not be desirable.

You could do 'param = enum{...} = default' I guess. But... no. Just no. :-)

> You could however just use the full spectrum of enum features:
>
> void DeleteFile(enum : short{flag1, flag2} options); // declares a
> non-class enum with underlying type short that allows to combine the flags

....except how do I name the parameter values outside the call site?
(Especially when you start talking about flags, I will *definitely* want
to do this.)

Again, though, your proposal doesn't allow use of a hypothetical
std::flags for type-safe flag operations. The 'function scope' proposal
would allow this (and also solves the naming problem).

> void DeleteFile(enum class {option1, option2} options);

As appalling as I find the notion of giving the parameter as 'enum
{...}' in the declaration and 'int' in the definition (which I guess you
are suggesting would work), I can't do that in this case. So how do I
give the parameter type in the definition?

(Hmm... 'auto'? Should we (in general) allow the type of a function
parameter to be 'auto' if the function has been previously defined? So
long as enough parameters have concrete types as to determine an
unambiguous overload, I don't see why this couldn't work...)

--
Matthew

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"><meta http-equiv=3D"Content-Type" content=3D"text/html cha=
rset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-n=
bsp-mode: space; -webkit-line-break: after-white-space;" dir=3D"auto"><br><=
div><div>On 2014&ndash;06&ndash;11, at 3:33 AM, Andrew Tomazos &lt;<a href=
=3D"mailto:andrewtomazos@gmail.com">andrewtomazos@gmail.com</a>&gt; wrote:<=
/div><br class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div=
 dir=3D"ltr">I think there might be something in this. &nbsp;Perhaps a gene=
ralization of your idea is to introduce the notion of a function name scope=
.. &nbsp;</div></blockquote><div><br></div><div>+1, this has crossed my mind=
 a few times.</div><div><br></div><div>The scope of the enumeration (and if=
 it&rsquo;s unscoped, its enumerators) would be the signature of the functi=
on and its body. Taxonomically it would be a local type. The enumerators ar=
e also in scope in function call argument lists for the function.</div><div=
><br></div><div>The question is, how does the compiler keep track of enumer=
ator names? Perhaps, as the function name is parsed first, and an overload =
set may be found before parsing the argument list, function-specific names =
may be looked up given the context of the overload set.</div><div><br></div=
><div>This sounds doable, but it&rsquo;s sure to be nontrivial for implemen=
tation. It comes down to cost/benefit.</div><div><br></div><div>Also, it wo=
uld be very unintuitive for function-specific enumerators to hide local nam=
es in general, but it could also be unintuitive for the local name to hide =
a highly specific enumerator which is being passed to its own dedicated fun=
ction argument slot. The user shouldn&rsquo;t be presented with a dilemma.<=
/div><div><br></div><div>Keeping everything simple, let&rsquo;s say that fu=
nction-specific enumerations must be scoped, therefore there are no implici=
t conversions to or from integer type. Since the enumeration type is not in=
 scope at call sites in other functions, there are no explicit conversions =
either, no operators, and no way to obtain an argument value besides naming=
 an enumerator.</div><div><br></div><div>Then, even if the enumerator name =
collides with a local, we can be certain that the enumerator is the user's =
intended meaning. (Recursive function calls may still satisfy the parameter=
 type with nontrivial arguments, but there&rsquo;s no potential problem the=
re.)</div><div><br></div><div>This seems like a good solution. What do you =
guys think?</div><br><blockquote type=3D"cite"><div dir=3D"ltr">Names can b=
e introduced into the function name scope of a function F by syntax in the =
declarations of the function F. &nbsp;A name N in function name scope can b=
e looked up with qualified lookup on the function name F::N</div></blockquo=
te><div><br></div><div>I don&rsquo;t like this: qualifying the function arg=
uments with the function name puts an excessive cost on long function names=
, and leads to repetition anyway.</div><br><blockquote type=3D"cite"><div d=
ir=3D"ltr">, or unqualified from within the function definition of F. &nbsp=
;This would allow you to introduce entities that are specific to a function=
 (for a specific example an enumeration used by one of its parameters or re=
turn value).</div></blockquote></div><br><div>The enumeration should be spe=
cific to a particular parameter. The user shouldn&rsquo;t access it otherwi=
se. The implementer shouldn&rsquo;t need to qualify it within function impl=
ementation.</div><div><br></div><div><blockquote type=3D"cite">So these two=
 declarations would declare the same function:<br><br>void DeleteFile(int o=
ptions);<br>void DeleteFile(enum{opt1, opt2} options);<br><br>The same way =
that<br><br>void foo(int p);<br>void foo(int p =3D 1);<br></blockquote><br>=
</div><div>Eh, enumerations are distinct types. It might be better to lever=
age something like opaque enumeration declarations:</div><div><br></div><fo=
nt face=3D"Courier">enum class abc : short; // OK: opaque enumeration decla=
ration<br></font><div><font face=3D"Courier">enum class abc : short { a, b,=
 c }; // OK: fully define enumeration<br>enum class abc : short; // OK: red=
eclare existing enumeration<br></font><br></div><div>So it could all look l=
ike this:</div><div><br></div><div><font face=3D"Courier">// prototype</fon=
t></div><div><font face=3D"Courier">void DeleteFile(</font></div><div><font=
 face=3D"Courier">&nbsp; &nbsp; enum class recurse_opt { recursive, nonrecu=
rsive } =3D recurse_opt::nonrecursive,</font></div><div><font face=3D"Couri=
er">&nbsp; &nbsp; enum class force_opt { force, careful } =3D force_opt::ca=
reful</font></div><div><font face=3D"Courier">);</font></div><div><font fac=
e=3D"Courier"><br></font></div><div><font face=3D"Courier">// implementatio=
n</font></div><div><font face=3D"Courier">void DeleteFile( recurse_opt recu=
rse, force_opt force ) { // local types ideally already in scope</font></di=
v><div><font face=3D"Courier">&nbsp; &nbsp; if ( recurse =3D=3D recurse_opt=
::recursive ) ...&nbsp;</font></div><div><font face=3D"Courier">}</font></d=
iv><div><font face=3D"Courier"><br></font></div><div><font face=3D"Courier"=
>// use</font></div><div><font face=3D"Courier">DeleteFile( recursive, forc=
e );</font></div><div><br></div><div>The main prohibition is anonymous enum=
eration type.</div><div><br></div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

.

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


On Wednesday, 11 June 2014 23:09:28 UTC+1, jan.kr...@gmail.com wrote:=20
>
>  Actually the way I envisioned it is that the parameter is simply always=
=20
> an int, but that the enum part is like an "annotation" (or whatever you'd=
=20
> want to call it).
> Similar to a default value for a parameter.
>
> So,
=20
=20
 void fn(enum class : int {option_1, option_2} option) { // option actually=
=20
an int, not an enum      =20
  switch (option) {      =20
  case option_1: // illegal =E2=80=94 trying to compare an int to an enum c=
lass    =20
 =20
  // =E2=80=A6      =20
  }      =20
}

=20

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr"><BR>On Wednesday, 11 June 2014 23:09:28 UTC+1, jan.kr...@g=
mail.com wrote:=20
<BLOCKQUOTE style=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex=
; PADDING-LEFT: 1ex" class=3Dgmail_quote>
<DIV dir=3Dltr>
<DIV>Actually the way I envisioned it is that the parameter is simply alway=
s an int, but that the enum part is like an "annotation" (or whatever you'd=
 want to call it).<BR>Similar to a default value for a parameter.<BR><BR></=
DIV></DIV></BLOCKQUOTE>
<DIV>So,</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV style=3D"BORDER-BOTTOM: #bbb 1px solid; BORDER-LEFT: #bbb 1px solid; B=
ACKGROUND-COLOR: #fafafa; WORD-WRAP: break-word; BORDER-TOP: #bbb 1px solid=
; BORDER-RIGHT: #bbb 1px solid" class=3Dprettyprint><CODE class=3Dprettypri=
nt>
<DIV class=3Dsubprettyprint><SPAN style=3D"COLOR: #008" class=3Dstyled-by-p=
rettify>void</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> =
fn</SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-prettify>(</SPAN><SP=
AN style=3D"COLOR: #008" class=3Dstyled-by-prettify>enum</SPAN><SPAN style=
=3D"COLOR: #000" class=3Dstyled-by-prettify> </SPAN><SPAN style=3D"COLOR: #=
008" class=3Dstyled-by-prettify>class</SPAN><SPAN style=3D"COLOR: #000" cla=
ss=3Dstyled-by-prettify> </SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-=
by-prettify>:</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify>=
 </SPAN><SPAN style=3D"COLOR: #008" class=3Dstyled-by-prettify>int</SPAN><S=
PAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> </SPAN><SPAN style=3D=
"COLOR: #660" class=3Dstyled-by-prettify>{</SPAN><SPAN style=3D"COLOR: #000=
" class=3Dstyled-by-prettify>option_1</SPAN><SPAN style=3D"COLOR: #660" cla=
ss=3Dstyled-by-prettify>,</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-=
by-prettify> option_2</SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-p=
rettify>}</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> opt=
ion</SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-prettify>)</SPAN><S=
PAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> </SPAN><SPAN style=3D=
"COLOR: #660" class=3Dstyled-by-prettify>{</SPAN><SPAN style=3D"COLOR: #000=
" class=3Dstyled-by-prettify> </SPAN><SPAN style=3D"COLOR: #800" class=3Dst=
yled-by-prettify>// option actually an int, not an enum &nbsp; &nbsp; &nbsp=
;</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify>&nbsp;<BR>&n=
bsp; </SPAN><SPAN style=3D"COLOR: #008" class=3Dstyled-by-prettify>switch</=
SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> </SPAN><SPAN s=
tyle=3D"COLOR: #660" class=3Dstyled-by-prettify>(</SPAN><SPAN style=3D"COLO=
R: #000" class=3Dstyled-by-prettify>option</SPAN><SPAN style=3D"COLOR: #660=
" class=3Dstyled-by-prettify>)</SPAN><SPAN style=3D"COLOR: #000" class=3Dst=
yled-by-prettify> </SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-pret=
tify>{</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> &nbsp;=
 &nbsp; &nbsp;&nbsp;<BR>&nbsp; </SPAN><SPAN style=3D"COLOR: #008" class=3Ds=
tyled-by-prettify>case</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-=
prettify> option_1</SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-pret=
tify>:</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> </SPAN=
><SPAN style=3D"COLOR: #800" class=3Dstyled-by-prettify>// illegal =E2=80=
=94 trying to compare an int to an enum class &nbsp; &nbsp; &nbsp;</SPAN><S=
PAN style=3D"COLOR: #000" class=3Dstyled-by-prettify>&nbsp;<BR>&nbsp; </SPA=
N><SPAN style=3D"COLOR: #800" class=3Dstyled-by-prettify>// =E2=80=A6 &nbsp=
; &nbsp; &nbsp;</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettif=
y>&nbsp;<BR>&nbsp; </SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-pre=
ttify>}</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> &nbsp=
; &nbsp; &nbsp;&nbsp;<BR></SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-=
by-prettify>}</SPAN></DIV></CODE></DIV><BR>
<DIV>&nbsp;</DIV></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_115_15960348.1402568925541--

.

------=_Part_2394_24137010.1402573057768
Content-Type: text/plain; charset=UTF-8

I'm more against your proposition because it does not encourage reuse of
existing code.
In your example :

enum DeleteFileOptions { Recursive, NonRecursive };
  void DeleteFile(DeleteFileOptions option);

could be replaced by :

enum class RecursionMode { Recursive, NonRecursive };
void DeleteFile(eRecursionMode recursivity);

so that it could be reused here :
void copy_directory(RecursionMode recursivity);
file_iterator find_files(const std::string& pattern, RecursionMode
recursivity = RecursionMode::Recursive);
file_iterator list_directories(RecursionMode recursivity =
RecursionMode::Recursive);
//...

So I do believe that enums that are can only be relevant in one single call
is rather rare. Also, all of your method generally are placed inside at
least namespace (but more generally inside a class, even if the method
itself is declared static).
so your example will become more like this :

struct directory {
  enum mode { recursive, non_recursive };
  /*ctors*/
  //...
  /*methods*/
  void remove(mode m);//delete confilcts with the delete operator :-)
  void copy(mode m); //use the same enum
  static void remove(const std::string& path, mode m); //example of a
static method
};
//...

directory d(path);
d.remove(directory::non_recursive);
// OR
directory::remove(path, directory::non_recursive);

Do you think such enums are common enough for a core language change?
> I don't.


Basically, I don't think they are either.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div dir=3D"ltr">I'm more against your proposition because=
 it does not encourage reuse of existing code. <br>In your example :<br><br=
><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); =
border-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; w=
ord-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyp=
rint"><code><span style=3D"color:#000"></span><div class=3D"prettyprint" st=
yle=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 18=
7); border-style: solid; border-width: 1px; word-wrap: break-word;"><code c=
lass=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">enum</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"s=
tyled-by-prettify">DeleteFileOptions</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">R=
ecursive</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #606;" class=3D"styled-by-prettify">NonRecursive</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">};</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br>&nbsp; </span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">void</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" cla=
ss=3D"styled-by-prettify">DeleteFile</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">(</span><span style=3D"color: #606;" class=3D"sty=
led-by-prettify">DeleteFileOptions</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> option</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br></span></div></code></div><span style=3D"color:#000"><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"></span></span></code><=
/div></code></div><br><code><span style=3D"color:#000"><span style=3D"font-=
family: arial,sans-serif;">could be replaced by :<br><br><div class=3D"pret=
typrint" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(1=
87, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-wor=
d;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=
=3D"color: #606;" class=3D"styled-by-prettify"><code class=3D"prettyprint">=
<code><span style=3D"color:#008"><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">enum class</span></span><span style=3D"color:#000"><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span></span><span styl=
e=3D"color:#606"><span style=3D"color: #606;" class=3D"styled-by-prettify">=
RecursionMode </span></span><span style=3D"color:#660"><span style=3D"color=
: #660;" class=3D"styled-by-prettify">{</span></span><span style=3D"color:#=
000"><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span></sp=
an><span style=3D"color:#606"><span style=3D"color: #606;" class=3D"styled-=
by-prettify">Recursive</span></span><span style=3D"color:#660"><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span></span><span style=
=3D"color:#000"><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span></span><span style=3D"color:#606"><span style=3D"color: #606;" class=
=3D"styled-by-prettify">NonRecursive</span></span><span style=3D"color:#000=
"><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span></span>=
<span style=3D"color:#660"><span style=3D"color: #660;" class=3D"styled-by-=
prettify">};</span></span><span style=3D"color:#000"><span style=3D"color: =
#000;" class=3D"styled-by-prettify"><br></span></span><span style=3D"color:=
#008"><span style=3D"color: #008;" class=3D"styled-by-prettify">void</span>=
</span><span style=3D"color:#000"><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span></span><span style=3D"color:#606"><span style=3D"c=
olor: #606;" class=3D"styled-by-prettify">DeleteFile</span></span><span sty=
le=3D"color:#660"><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>(</span></span></code></code></span><span style=3D"color: #606;" class=3D"=
styled-by-prettify"><code class=3D"prettyprint"><code><span style=3D"color:=
#660"><span style=3D"color: #660;" class=3D"styled-by-prettify"><code><span=
 style=3D"color:#000"><span style=3D"font-family: arial,sans-serif;"><code =
class=3D"prettyprint"><span style=3D"color: #606;" class=3D"styled-by-prett=
ify"><code class=3D"prettyprint"><code><span style=3D"color:#000"><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"></span></span><span style=
=3D"color:#606"><span style=3D"color: #606;" class=3D"styled-by-prettify">e=
RecursionMode</span></span></code></code></span></code></span></span></code=
></span></span><span style=3D"color:#000"><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> recursivity</span></span><span style=3D"color:#66=
0"><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span></spa=
n><span style=3D"color:#000"><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"></span></span></code></code><br></span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify"></span></div></code></div><br>so that it =
could be reused here :<br><div class=3D"prettyprint" style=3D"background-co=
lor: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: so=
lid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"=
><div class=3D"subprettyprint"><code><span style=3D"color:#000"><span style=
=3D"font-family: arial,sans-serif;"><code class=3D"prettyprint"><span style=
=3D"color: #606;" class=3D"styled-by-prettify"><code><span style=3D"color:#=
000"><span style=3D"font-family: arial,sans-serif;"><code class=3D"prettypr=
int"><span style=3D"color: #606;" class=3D"styled-by-prettify"><code class=
=3D"prettyprint"><code><span style=3D"color:#008"><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">void</span></span><span style=3D"color:#00=
0"><span style=3D"color: #000;" class=3D"styled-by-prettify"> copy_director=
y</span></span><span style=3D"color:#660"><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">(</span></span></code></code></span><span style=3D=
"color: #606;" class=3D"styled-by-prettify"><code class=3D"prettyprint"><co=
de><span style=3D"color:#660"><span style=3D"color: #660;" class=3D"styled-=
by-prettify"><code><span style=3D"color:#000"><span style=3D"font-family: a=
rial,sans-serif;"><code class=3D"prettyprint"><span style=3D"color: #606;" =
class=3D"styled-by-prettify"><code class=3D"prettyprint"><code><span style=
=3D"color:#000"><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
/span></span><span style=3D"color:#606"><span style=3D"color: #606;" class=
=3D"styled-by-prettify">RecursionMode</span></span></code></code></span></c=
ode></span></span></code></span></span><span style=3D"color:#000"><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> recursivity</span></span>=
<span style=3D"color:#660"><span style=3D"color: #660;" class=3D"styled-by-=
prettify">);</span></span><span style=3D"color:#000"><span style=3D"color: =
#000;" class=3D"styled-by-prettify"></span></span></code></code></span></co=
de></span></span></code></span></code></span></span></code><br><code><span =
style=3D"color:#000"><span style=3D"font-family: arial,sans-serif;"><code c=
lass=3D"prettyprint"><code><span style=3D"color:#000"><span style=3D"font-f=
amily: arial,sans-serif;"><code class=3D"prettyprint"><span style=3D"color:=
 #606;" class=3D"styled-by-prettify"><code><span style=3D"color:#000"><span=
 style=3D"font-family: arial,sans-serif;"><code class=3D"prettyprint"><span=
 style=3D"color: #606;" class=3D"styled-by-prettify"><code class=3D"prettyp=
rint"><code>file_iterator<span style=3D"color:#000"><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> find_files</span></span><span style=3D"=
color:#660"><span style=3D"color: #660;" class=3D"styled-by-prettify">(cons=
t std::string&amp; pattern, </span></span></code></code></span><span style=
=3D"color: #606;" class=3D"styled-by-prettify"><code class=3D"prettyprint">=
<code><span style=3D"color:#660"><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify"><code><span style=3D"color:#000"><span style=3D"font-family=
: arial,sans-serif;"><code class=3D"prettyprint"><span style=3D"color: #606=
;" class=3D"styled-by-prettify"><code class=3D"prettyprint"><code><span sty=
le=3D"color:#000"><span style=3D"color: #000;" class=3D"styled-by-prettify"=
></span></span><span style=3D"color:#606"><span style=3D"color: #606;" clas=
s=3D"styled-by-prettify">RecursionMode</span></span></code></code></span></=
code></span></span></code></span></span><span style=3D"color:#000"><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> recursivity</span></span=
><span style=3D"color:#660"><span style=3D"color: #660;" class=3D"styled-by=
-prettify"> =3D </span></span></code></code></span></code></span></span></c=
ode></span></code></span></span></code></code></span></span></code><code><s=
pan style=3D"color:#000"><span style=3D"font-family: arial,sans-serif;"><co=
de class=3D"prettyprint"><code><span style=3D"color:#000"><span style=3D"fo=
nt-family: arial,sans-serif;"><code class=3D"prettyprint"><span style=3D"co=
lor: #606;" class=3D"styled-by-prettify"><code><span style=3D"color:#000"><=
span style=3D"font-family: arial,sans-serif;"><code class=3D"prettyprint"><=
span style=3D"color: #606;" class=3D"styled-by-prettify"><code class=3D"pre=
ttyprint"><code><span style=3D"color:#660"><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify"><code><span style=3D"color:#000"><span style=3D"f=
ont-family: arial,sans-serif;"><code class=3D"prettyprint"><span style=3D"c=
olor: #606;" class=3D"styled-by-prettify"><code class=3D"prettyprint"><code=
><span style=3D"color:#606"><span style=3D"color: #606;" class=3D"styled-by=
-prettify">RecursionMode::Recursive</span></span></code></code></span></cod=
e></span></span></code>);</span></span><span style=3D"color:#000"><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"></span></span></code></cod=
e></span></code></span></span></code></span></code></span></span></code></c=
ode></span></span></code><br><code><span style=3D"color:#000"><span style=
=3D"font-family: arial,sans-serif;"><code class=3D"prettyprint"><code><span=
 style=3D"color:#000"><span style=3D"font-family: arial,sans-serif;"><code =
class=3D"prettyprint"><code><span style=3D"color:#000"><span style=3D"font-=
family: arial,sans-serif;"><code class=3D"prettyprint"><span style=3D"color=
: #606;" class=3D"styled-by-prettify"><code><span style=3D"color:#000"><spa=
n style=3D"font-family: arial,sans-serif;"><code class=3D"prettyprint"><spa=
n style=3D"color: #606;" class=3D"styled-by-prettify"><code class=3D"pretty=
print"><code>file_iterator<span style=3D"color:#000"><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> list</span></span><span style=3D"color=
:#660"><span style=3D"color: #660;" class=3D"styled-by-prettify">_directori=
es(</span></span></code></code></span><span style=3D"color: #606;" class=3D=
"styled-by-prettify"><code class=3D"prettyprint"><code><span style=3D"color=
:#660"><span style=3D"color: #660;" class=3D"styled-by-prettify"><code><spa=
n style=3D"color:#000"><span style=3D"font-family: arial,sans-serif;"><code=
 class=3D"prettyprint"><span style=3D"color: #606;" class=3D"styled-by-pret=
tify"><code class=3D"prettyprint"><code><span style=3D"color:#000"><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"></span></span><span style=
=3D"color:#606"><span style=3D"color: #606;" class=3D"styled-by-prettify">R=
ecursionMode</span></span></code></code></span></code></span></span></code>=
</span></span><span style=3D"color:#000"><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> recursivity</span></span><span style=3D"color:#660=
"><span style=3D"color: #660;" class=3D"styled-by-prettify"> =3D </span></s=
pan></code></code></span></code></span></span></code></span></code></span><=
/span></code></code></span></span></code><code><span style=3D"color:#000"><=
span style=3D"font-family: arial,sans-serif;"><code class=3D"prettyprint"><=
code><span style=3D"color:#000"><span style=3D"font-family: arial,sans-seri=
f;"><code class=3D"prettyprint"><span style=3D"color: #606;" class=3D"style=
d-by-prettify"><code><span style=3D"color:#000"><span style=3D"font-family:=
 arial,sans-serif;"><code class=3D"prettyprint"><span style=3D"color: #606;=
" class=3D"styled-by-prettify"><code class=3D"prettyprint"><code><span styl=
e=3D"color:#660"><span style=3D"color: #660;" class=3D"styled-by-prettify">=
<code><span style=3D"color:#000"><span style=3D"font-family: arial,sans-ser=
if;"><code class=3D"prettyprint"><span style=3D"color: #606;" class=3D"styl=
ed-by-prettify"><code class=3D"prettyprint"><code><span style=3D"color:#606=
"><span style=3D"color: #606;" class=3D"styled-by-prettify">RecursionMode::=
Recursive</span></span></code></code></span></code></span></span></code>);<=
/span></span><span style=3D"color:#000"><span style=3D"color: #000;" class=
=3D"styled-by-prettify"></span></span></code></code></span></code></span></=
span></code></span></code></span></span></code></code></span></span></code>=
</code></span></span></code><br>//...<br><span style=3D"color: #660;" class=
=3D"styled-by-prettify"></span></div></code></div><br>So I do believe that =
enums that are can only be relevant in one single call is rather rare. Also=
, all of your method generally are placed inside at least namespace (but mo=
re generally inside a class, even if the method itself is declared static).=
 <br>so your example will become more like this :<br><div class=3D"prettypr=
int" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, =
187, 187); border-style: solid; border-width: 1px; word-wrap: break-word;">=
<code class=3D"prettyprint"><div class=3D"subprettyprint"><div><br></div><d=
iv style=3D"background-color:rgb(250,250,250);border:1px solid rgb(187,187,=
187);word-wrap:break-word"><code><div><span style=3D"color:#008">struct</sp=
an><span style=3D"color:#000"> directory </span><span style=3D"color:#660">=
{</span><span style=3D"color:#000"><br>&nbsp; </span><span style=3D"color:#=
008">enum</span><span style=3D"color:#000"> mode </span><span style=3D"colo=
r:#660">{</span><span style=3D"color:#000"> </span><span style=3D"color:#60=
6">recursive, </span><code><span style=3D"color:#000"><span style=3D"font-f=
amily: arial,sans-serif;"><code class=3D"prettyprint"><span style=3D"color:=
 #606;" class=3D"styled-by-prettify"><code class=3D"prettyprint"><code><spa=
n style=3D"color:#606"><span style=3D"color: #606;" class=3D"styled-by-pret=
tify">non_recursive</span></span></code></code></span></code></span></span>=
</code><span style=3D"color:#000"> </span><span style=3D"color:#660">};</sp=
an><span style=3D"color:#000"><br>&nbsp; /*ctors*/<br>&nbsp; //...<br>&nbsp=
; /*methods*/<br></span><span style=3D"color:#008">&nbsp; void</span><span =
style=3D"color:#000"> remove</span><span style=3D"color:#660">(</span><span=
 style=3D"color:#000">mode m</span><span style=3D"color:#660">);</span><spa=
n style=3D"color:#000">//delete confilcts with the delete operator :-)<br>&=
nbsp; void copy(</span><span style=3D"color:#000"><code><span style=3D"colo=
r:#000"><span style=3D"font-family: arial,sans-serif;"><code class=3D"prett=
yprint"><code><span style=3D"color:#000">mode m</span><span style=3D"color:=
#660">);</span><span style=3D"color:#000"></span></code></code></span></spa=
n></code> //use the same enum <br>&nbsp; static void remove(const std::stri=
ng&amp; path, </span><code><span style=3D"color:#000"><span style=3D"font-f=
amily: arial,sans-serif;"><code class=3D"prettyprint"><code><span style=3D"=
color:#000">mode m</span></code></code></span></span></code>); //example of=
 a static method<code><span style=3D"color:#000"><span style=3D"font-family=
: arial,sans-serif;"><code class=3D"prettyprint"><code><span style=3D"color=
:#000"><br></span></code></code></span></span></code><span style=3D"color:#=
660">};<br>//...<br><br></span><span style=3D"color:#000"></span><span styl=
e=3D"color:#606"></span>directory d(path);<br>d.remove(<code><span style=3D=
"color:#000"><span style=3D"font-family: arial,sans-serif;"><code class=3D"=
prettyprint"><code><span style=3D"color:#000">directory::</span></code></co=
de></span></span></code><code><span style=3D"color:#000"><span style=3D"fon=
t-family: arial,sans-serif;"><code class=3D"prettyprint"><code><span style=
=3D"color:#606"></span><code><span style=3D"color:#000"><span style=3D"font=
-family: arial,sans-serif;"><code class=3D"prettyprint"><span style=3D"colo=
r: #606;" class=3D"styled-by-prettify"><code class=3D"prettyprint"><code><s=
pan style=3D"color:#606"><span style=3D"color: #606;" class=3D"styled-by-pr=
ettify">non_recursive</span></span></code></code></span></code></span></spa=
n></code><span style=3D"color:#000">);<br>// OR<br></span></code></code></s=
pan></span></code><code><span style=3D"color:#000"><span style=3D"font-fami=
ly: arial,sans-serif;"><code class=3D"prettyprint"><code>directory::remove(=
path, </code></code></span></span></code><code><span style=3D"color:#000"><=
span style=3D"font-family: arial,sans-serif;"><code class=3D"prettyprint"><=
code><code><span style=3D"color:#000"><span style=3D"font-family: arial,san=
s-serif;"><code class=3D"prettyprint"><code><span style=3D"color:#000">dire=
ctory::</span></code></code></span></span></code><code><span style=3D"color=
:#000"><span style=3D"font-family: arial,sans-serif;"><code class=3D"pretty=
print"><code><span style=3D"color:#606"></span><code><span style=3D"color:#=
000"><span style=3D"font-family: arial,sans-serif;"><code class=3D"prettypr=
int"><span style=3D"color: #606;" class=3D"styled-by-prettify"><code class=
=3D"prettyprint"><code><span style=3D"color:#606"><span style=3D"color: #60=
6;" class=3D"styled-by-prettify">non_recursive</span></span></code></code><=
/span></code></span></span></code><span style=3D"color:#000">);</span></cod=
e></code></span></span></code></code></code></span></span></code></div></co=
de></div></div></code></div><br></span></span></code><code><span style=3D"c=
olor:#000"><span style=3D"font-family: arial,sans-serif;"></span></span></c=
ode><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid =
rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote">Do you think =
such enums are common enough for a core language change?
<br>I don't.
</blockquote><div><br>Basically, I don't think they are either.<br></div><c=
ode><span style=3D"color:#000"><span style=3D"font-family: arial,sans-serif=
;"><br></span></span></code></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2394_24137010.1402573057768--

.

On 2014-06-12 01:42, David Krauss wrote:
> On 2014=E2=80=9306=E2=80=9311, at 3:33 AM, Andrew Tomazos wrote:
>> Names can be introduced into the function name scope of a function F by =
syntax=20
>> in the declarations of the function F.  A name N in function name scope =
can be=20
>> looked up with qualified lookup on the function name F::N
>=20
> I don=E2=80=99t like this: qualifying the function arguments with the fun=
ction name puts=20
> an excessive cost on long function names, and leads to repetition anyway.

I think the point here is that they can be looked up *outside* of the
function argument list, which I think is important.

Within the function argument list, we want the function scope to be used
for lookup.

IOW, both of these are legal:

  auto mode =3D DeleteFiles::Recursive; // named outside of call
  DeleteFiles(mode);

  DeleteFiles(Recursive); // no need to repeat scope when part of call

> So it could all look like this:
>=20
> // prototype
> void DeleteFile(
>      enum class recurse_opt { recursive, nonrecursive } =3D recurse_opt::=
nonrecursive,
>      enum class force_opt { force, careful } =3D force_opt::careful
> );

I'd argue that in this case one shouldn't need to repeat the enum name
to qualify the enum value. (Of course, that's a problem with enum class
in general, as I've mentioned previously.)

> // use
> DeleteFile( recursive, force );

Wait... how come *here* you don't need to qualify the enum values?

--=20
Matthew

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On 2014-06-12 13:47, David Krauss wrote:
> On 2014-06-13, at 12:00 AM, Matthew Woehlke wrote:
>>  auto mode =3D DeleteFiles::Recursive; // named outside of call
>>  DeleteFiles(mode);
>>
>>  DeleteFiles(Recursive); // no need to repeat scope when part of call
>=20
> It's certainly a use-case, but I think the feature is mainly applicable w=
hen it's anticipated with some certainty that the user will not be calculat=
ing the argument. If the user declares a named variable, it might as well b=
e called recursiveness and then the problem has already gone away. The orig=
inal problem is simply that it's too easy to pass true or false and be done=
 with it.
>=20
> If the call can go either way, DeleteFiles( recurse? recursive : non_recu=
rsive ) might be a reasonable form. This is an exception to my "no operator=
s" rule, but still not too complicated.

Where I see this going entirely sideways is if the parameter is a flags
(or even multiple choice) rather than better-named true/false.

Especially in the flags case, having full-blown function scopes, as I
suggested, would allow other extensions (e.g. a hypothetical std::flags)
to be used seamlessly, whereas with the original proposal of defining
the enum inline in the parameter list, such extensions would require an
additional language change to be used. For this and other reasons, I
feel that my proposal is far more flexible with similar implementation cost=
..

As another example, with my suggestion you could define function-local
convenience typedefs, constant values, etc.

This example is fairly contrived, but:

  function DeleteFiles
  {
    using enum class recurse_opt { recursive, nonrecursive };
    const default_recurse =3D nonrecursive;
    operator()(recurse_opt =3D default_recurse);
  };

It's a little bit more typing, but not a lot ("function", "operator()",
";", "{", "};" and some (optional) whitespace).

For that matter, I suppose we could even omit the "operator()" and
instead write:

  function <function name> {
    <scope members>
  }(<parameter list>)
  <definition or ';'>

(Text in <>'s are placeholders; <>'s are not literal.)

I'm not sure if I'd like that better, though, and it removed the
possibility to add other operators (although that might be a good thing).

OTOH, I can imagine doing things like:

  function func1 {...};
  auto f =3D &func1;
  (*f)(...); // call func1
  auto c =3D func1 + func2; // function composition

(...assuming that 'func1' defines an operator+ which returns e.g. a
std::function, or possibly a lambda. Of course this is somewhat
limiting, since operator+ would only work for functions that
specifically support it, but it's just an exercise in why other
operators could be interesting.)

>>> // prototype
>>> void DeleteFile(
>>>     enum class recurse_opt { recursive, nonrecursive } =3D recurse_opt:=
:nonrecursive,
>>>     enum class force_opt { force, careful } =3D force_opt::careful
>>> );
>>>
>>> // use
>>> DeleteFile( recursive, force );
>>
>> Wait... how come *here* you don't need to qualify the enum values?
>=20
> Same as your reason. The call is used to produce lookup context, to avoid=
 repetition.

....except 'recursive' is still not in scope, in this example. It would
still need to be 'recurse_opt::recursive'. (The "right" solution of
course is for the parent scope to inherit the enum values, as otherwise
stated. I was pointing out the inconsistency in order to seek
clarification; was this an oversight, or did you intend that the lookup
rules should work differently in this context?)

--=20
Matthew

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On 2014-06-12 21:37, Thiago Macieira wrote:
> Em qui 12 jun 2014, =C3=A0s 03:28:45, Douglas Boffey escreveu:
>>   switch (option) {      =20
>>   case option_1: // illegal =E2=80=94 trying to compare an int to an enu=
m class    =20
>>
>>   // =E2=80=A6      =20
>>   }      =20
>=20
> That is already allowed today. We can't break it.

Really? If option_1 is really a member of an enum class, g++ 4.8.2 (as
expected) gives me "error: could not convert =E2=80=98option_1=E2=80=99 fro=
m =E2=80=98option=E2=80=99 to
=E2=80=98int=E2=80=99" (also "from =E2=80=98int=E2=80=99 to =E2=80=98option=
=E2=80=99" if the switch is over the enum and
the cases are int). I sincerely hope this is correct behavior, as it is
clearly in line with the intent than an enum class is not implicitly
convertible.

--=20
Matthew

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On 2014-06-12 23:08, David Krauss wrote:
> On 2014-06-13, at 2:14 AM, Matthew Woehlke wrote:
>>  function DeleteFiles
>>  {
>>    using enum class recurse_opt { recursive, nonrecursive };
>>    const default_recurse = nonrecursive;
>>    operator()(recurse_opt = default_recurse);
>>  };
>
> You might as well just define a functor class. Seems to be where this is generally heading.

Yes, that's essentially the idea. The key difference is that there is no
instantiation of the 'function' as an object, as there would be with a
'true functor class'.

>>> // use
>>> DeleteFile( recursive, force );
>
> My proposal does not place recurse_opt in scope. If it were in scope, you could use the enumeration name to form a cast expression.

Then I am confused; how can you use a member of the enum ("recursive")
without qualifying it? Do I miss something?

> Yes, I explained it in my initial post. Lookup inside an argument for
> a function-scope enumeration parameter would consider the
> enumerators.

Ah, that's what I missed. Hmm... I guess I can live with it, although I
would suggest that only those enumerations are considered which are the
type of the parameter for which lookup is being performed.

> Perhaps non-function-scope enumerator types

I don't think this should be done as a general rule. Given a bunch of
'enum class's in a large namespace, this would lead to pollution of the
parent namespace and the same problems we had before enum class. (As you
undoubtedly know from how many times I've said it before, I do think we
need the ability to selectively turn off strong scoping, though.)

> and all initializers of scoped enumeration objects, should get the
> same treatment

That seems sensible.

> However, the implementation effort is probably significant.

For the first and third, alas, probably. For the second I don't think it
should be overly difficult given an explicit request to alias, as
compilers already need to do that sort of thing anyway.

>> (The "right" solution of course is for the parent scope to inherit
>> the enum values, as otherwise stated.
>
> Then you might as well declare enumeration in the function's parent scope. That's the current practice.

No; the point is to allow enum *class* members to be named from their
parent scope (the function). IOW, "DeleteFiles::recursive" instead of
"DeleteFiles::recursive_opt::recursive". Per your rules above this
wouldn't apply to parameters (which is perhaps where our communication
is breaking down), but to naming the values outside of a call of the
function.

> Note, if all you want is to have the nested-name-specifier match the function name, you can already do that because enumerations can alias functions, but functions are ignored by lookup from a nested-name-specifier.
>
> enum class DeleteFiles : bool {
>     nonrecursive = false, recursive,
>     careful = false, force
> };
>
> void DeleteFiles( enum DeleteFiles, enum DeleteFiles ) {
> }

I think this speaks for itself why it is inadequate :-).

--
Matthew

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2014-06-13 15:22, Thiago Macieira wrote:
> Em sex 13 jun 2014, =C3=A0s 11:56:46, Matthew Woehlke escreveu:
>> On 2014-06-12 21:37, Thiago Macieira wrote:
>>> Em qui 12 jun 2014, =C3=A0s 03:28:45, Douglas Boffey escreveu:
>>>>   switch (option) {
>>>>   case option_1: // illegal =E2=80=94 trying to compare an int to an e=
num class
>>>>  =20
>>>>   // =E2=80=A6
>>>>   }
>>>
>>> That is already allowed today. We can't break it.
>>
>> Really? If option_1 is really a member of an enum class, g++ 4.8.2 (as
>> expected) gives me "error: could not convert =E2=80=98option_1=E2=80=99 =
from =E2=80=98option=E2=80=99 to
>> =E2=80=98int=E2=80=99" (also "from =E2=80=98int=E2=80=99 to =E2=80=98opt=
ion=E2=80=99" if the switch is over the enum and
>> the cases are int). I sincerely hope this is correct behavior, as it is
>> clearly in line with the intent than an enum class is not implicitly
>> convertible.
>=20
> Sorry, I missed the "class" in the original declaration.

:-)

Without the all-important "class", you are right that the code above is
and should be legal.

--=20
Matthew

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

Em ter 10 jun 2014, =E0s 22:26:07, Ville Voutilainen escreveu:
> 1) Why don't you place the enums and the functions inside a namespace?
> 2) Why don't you place the enums and the functions inside a class?

These questions were never answered.

I still don't understand what problem needs to be solved here...
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

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

On 13 June 2014 22:55, Thiago Macieira <thiago@macieira.org> wrote:

> Em ter 10 jun 2014, =C3=A0s 22:26:07, Ville Voutilainen escreveu:
> > 1) Why don't you place the enums and the functions inside a namespace?
> > 2) Why don't you place the enums and the functions inside a class?
>
> These questions were never answered.
>

I'm pretty sure I did. To summarize: you *can,* but people typically *don't
*for single use types.
--=20
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr">On 13 June 2014 22:55, Thiago Macieira <span dir=3D"ltr">&=
lt;<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira=
..org</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmai=
l_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Em ter 10 jun 2014, =C3=A0s 22:26:07, Ville =
Voutilainen escreveu:<br>
<div class=3D"">&gt; 1) Why don&#39;t you place the enums and the functions=
 inside a namespace?<br>
&gt; 2) Why don&#39;t you place the enums and the functions inside a class?=
<br>
<br>
</div>These questions were never answered.<br></blockquote><div><br></div><=
div>I&#39;m pretty sure I did. To summarize: you <i>can,</i> but people typ=
ically <i>don&#39;t </i>for single use types.</div><div>--=C2=A0<br></div><=
/div>

=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@=
eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=C2=A0 (8=
47) 691-1404
</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--f46d0435c0522f576004fbc4273e--

.

Em sex 13 jun 2014, =E0s 23:22:35, Nevin Liber escreveu:
> On 13 June 2014 22:55, Thiago Macieira <thiago@macieira.org> wrote:
> > Em ter 10 jun 2014, =E0s 22:26:07, Ville Voutilainen escreveu:
> > > 1) Why don't you place the enums and the functions inside a namespace=
?
> > > 2) Why don't you place the enums and the functions inside a class?
> >=20
> > These questions were never answered.
>=20
> I'm pretty sure I did. To summarize: you *can,* but people typically *don=
't
> *for single use types.

I'd say that assuming things will be single-use is short-sighted in API=20
design. You never know what you'll need to do later, so it's actually bette=
r=20
to have an external enum that can be used in other contexts.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

--Apple-Mail=_BCFE86A6-3BA3-4A6C-87AA-037F7696A513
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-06-14, at 12:52 PM, Thiago Macieira <thiago@macieira.org> wrote:

> Em sex 13 jun 2014, =E0s 23:22:35, Nevin Liber escreveu:
>> On 13 June 2014 22:55, Thiago Macieira <thiago@macieira.org> wrote:
>>> Em ter 10 jun 2014, =E0s 22:26:07, Ville Voutilainen escreveu:
>>>> 1) Why don't you place the enums and the functions inside a namespace?
>>>> 2) Why don't you place the enums and the functions inside a class?
>>>=20
>>> These questions were never answered.
>>=20
>> I'm pretty sure I did. To summarize: you *can,* but people typically *do=
n't
>> *for single use types.
>=20
> I'd say that assuming things will be single-use is short-sighted in API=
=20
> design. You never know what you'll need to do later, so it's actually bet=
ter=20
> to have an external enum that can be used in other contexts.

Often true, but that philosophy can also lead to enum Bool { True, Flase, F=
ileNotFound };.=20

Encapsulation is often also a good choice. But nothing's worse than naked b=
ool parameters.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_BCFE86A6-3BA3-4A6C-87AA-037F7696A513
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;06&ndash;14, at 12:52 PM, Thiago Macieira &lt;<a href=3D"mailto:thiag=
o@macieira.org">thiago@macieira.org</a>&gt; wrote:</div><br class=3D"Apple-=
interchange-newline"><blockquote type=3D"cite">Em sex 13 jun 2014, =E0s 23:=
22:35, Nevin Liber escreveu:<br><blockquote type=3D"cite">On 13 June 2014 2=
2:55, Thiago Macieira &lt;<a href=3D"mailto:thiago@macieira.org">thiago@mac=
ieira.org</a>&gt; wrote:<br><blockquote type=3D"cite">Em ter 10 jun 2014, =
=E0s 22:26:07, Ville Voutilainen escreveu:<br><blockquote type=3D"cite">1) =
Why don't you place the enums and the functions inside a namespace?<br>2) W=
hy don't you place the enums and the functions inside a class?<br></blockqu=
ote><br>These questions were never answered.<br></blockquote><br>I'm pretty=
 sure I did. To summarize: you *can,* but people typically *don't<br>*for s=
ingle use types.<br></blockquote><br>I'd say that assuming things will be s=
ingle-use is short-sighted in API <br>design. You never know what you'll ne=
ed to do later, so it's actually better <br>to have an external enum that c=
an be used in other contexts.<br></blockquote><div><br></div><div>Often tru=
e, but that philosophy can also lead to&nbsp;<a href=3D"http://thedailywtf.=
com/Articles/What_Is_Truth_0x3f_.aspx"><font face=3D"Courier">enum Bool { T=
rue, Flase, FileNotFound };</font></a>.&nbsp;</div></div><br><div>Encapsula=
tion is often also a good choice. But nothing&rsquo;s worse than naked <fon=
t face=3D"Courier">bool</font> parameters.</div><div><br></div></body></htm=
l>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_BCFE86A6-3BA3-4A6C-87AA-037F7696A513--

.

------=_Part_1816_10868018.1402954963143
Content-Type: text/plain; charset=UTF-8

Some problems with local enums:

1) When you want to construct the enum value at runtime before calling the
function. Making them function local essentially forces you to initialize
the enum argument with a compile time constant.

i.e. you can't do something like this:

void display(Screen& target, enum { kMode1, kMode2} mode);

/*What is the type??*/ mode = getDisplayModeFromFile();
display(target, mode);

If people start using local enums, they will heavily restrict the users of
their interface, unless we add some way to get at the type this feature is
dead in my opinion.

//long and ugly.. We trading writing the external enum type for this.
std::get_me_reflection<decltype(display)>::value::mode mode =
getDisplayModeFromFile();

2) The type of display itself is now unknowable. Creating a function
pointer to it will require using type deduction techniques, i.e.
decltype(display). Maybe this is not too bad?

3) We have to invent more name lookup rules at the call site. This is
really hairy.

int kMode1 = 0;
display(target, 100.0, kMode1); //OK, should prefer function declaration
scope here

But imagine this:

void display(Screen& target, float ratio, enum {kMode1, kMode2} mode);

display(target, x+y, kMode1);

If tomorrow the author of display() adds a new enum value named x or y,
then could he silently break the caller's code? The enum name scope
therefore has to be limited to just the single expression (between the
commas) used to initialize the enum. Even there, I bet someone can concoct
a more complex example which still silently breaks when a name clash is
introduced.


--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">Some problems with local enums:<br><br>1) When you want to=
 construct the enum=20
value at runtime before calling the function. Making them function local=20
essentially forces you to initialize the enum argument with a compile time=
=20
constant.<br><br>i.e. you can't do something like this:<br><br>void display=
(Screen&amp; target, enum { kMode1, kMode2} mode);<br><br>/*What is the typ=
e??*/ mode =3D getDisplayModeFromFile();<br>display(target, mode);<br><br>I=
f people start using local enums, they will heavily restrict the users of t=
heir interface, unless we add some way to get at the type this feature is d=
ead in my opinion.<br><br>//long and ugly.. We trading writing the external=
 enum type for this.<br>std::get_me_reflection&lt;decltype(display)&gt;::va=
lue::mode mode =3D getDisplayModeFromFile();<br><br>2) The type of display =
itself is now unknowable. Creating a function pointer to it will require us=
ing type deduction techniques, i.e. decltype(display). Maybe this is not to=
o bad?<br><br>3) We have to invent more name lookup rules at the call site.=
 This is really hairy.<br><br>int kMode1 =3D 0;<br>display(target, 100.0, k=
Mode1); //OK, should prefer function declaration scope here<br><br>But imag=
ine this:<br><br>void display(Screen&amp; target, float ratio, enum {kMode1=
, kMode2} mode);<br><br>display(target, x+y, kMode1);<br><br>If tomorrow th=
e author of display() adds a new enum value named x or y, then could he sil=
ently break the caller's code? The enum name scope therefore has to be limi=
ted to just the single expression (between the commas) used to initialize t=
he enum. Even there, I bet someone can concoct a more complex example which=
 still silently breaks when a name clash is introduced.<br><br><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1816_10868018.1402954963143--

.

Em seg 16 jun 2014, =E0s 14:42:43, Matthew Fioravante escreveu:
> Some problems with local enums:
>=20
> 1) When you want to construct the enum value at runtime before calling th=
e
> function. Making them function local essentially forces you to initialize
> the enum argument with a compile time constant.
>=20
> i.e. you can't do something like this:
>=20
> void display(Screen& target, enum { kMode1, kMode2} mode);
>=20
> /*What is the type??*/ mode =3D getDisplayModeFromFile();
> display(target, mode);
[snip]

Matthew, thanks for those examples. They show clearly why I think function-
local enums as they're being proposed are too limited. In other words, your=
=20
examples are very good counter-examples to this feature.

Let people write enums outside the function because, invariably, they get u=
sed=20
in other contexts. Assuming that they will always be written literally at t=
he=20
call site is short-sighted.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

--001a1133c6ce69a49c04fbfda740
Content-Type: text/plain; charset=UTF-8

I think it should be reasonably easy to come up with sensible name lookup
rules; 3.4.2p3 would be the obvious starting point.
 On 16 Jun 2014 22:42, "Matthew Fioravante" <fmatthew5876@gmail.com> wrote:

> Some problems with local enums:
>
> 1) When you want to construct the enum value at runtime before calling the
> function. Making them function local essentially forces you to initialize
> the enum argument with a compile time constant.
>
> i.e. you can't do something like this:
>
> void display(Screen& target, enum { kMode1, kMode2} mode);
>
> /*What is the type??*/ mode = getDisplayModeFromFile();
> display(target, mode);
>
> If people start using local enums, they will heavily restrict the users of
> their interface, unless we add some way to get at the type this feature is
> dead in my opinion.
>
> //long and ugly.. We trading writing the external enum type for this.
> std::get_me_reflection<decltype(display)>::value::mode mode =
> getDisplayModeFromFile();
>
> 2) The type of display itself is now unknowable. Creating a function
> pointer to it will require using type deduction techniques, i.e.
> decltype(display). Maybe this is not too bad?
>
> 3) We have to invent more name lookup rules at the call site. This is
> really hairy.
>
> int kMode1 = 0;
> display(target, 100.0, kMode1); //OK, should prefer function declaration
> scope here
>
> But imagine this:
>
> void display(Screen& target, float ratio, enum {kMode1, kMode2} mode);
>
> display(target, x+y, kMode1);
>
> If tomorrow the author of display() adds a new enum value named x or y,
> then could he silently break the caller's code? The enum name scope
> therefore has to be limited to just the single expression (between the
> commas) used to initialize the enum. Even there, I bet someone can concoct
> a more complex example which still silently breaks when a name clash is
> introduced.
>
>
>  --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/bDv6TUntNzE/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<p dir=3D"ltr">I think it should be reasonably easy to come up with sensibl=
e name lookup rules; 3.4.2p3 would be the obvious starting point.<br>
</p>
<div class=3D"gmail_quote">On 16 Jun 2014 22:42, &quot;Matthew Fioravante&q=
uot; &lt;<a href=3D"mailto:fmatthew5876@gmail.com">fmatthew5876@gmail.com</=
a>&gt; wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">Some problems with local enums:<br><br>1) When you want to=
 construct the enum=20
value at runtime before calling the function. Making them function local=20
essentially forces you to initialize the enum argument with a compile time=
=20
constant.<br><br>i.e. you can&#39;t do something like this:<br><br>void dis=
play(Screen&amp; target, enum { kMode1, kMode2} mode);<br><br>/*What is the=
 type??*/ mode =3D getDisplayModeFromFile();<br>display(target, mode);<br>
<br>If people start using local enums, they will heavily restrict the users=
 of their interface, unless we add some way to get at the type this feature=
 is dead in my opinion.<br><br>//long and ugly.. We trading writing the ext=
ernal enum type for this.<br>
std::get_me_reflection&lt;decltype(display)&gt;::value::mode mode =3D getDi=
splayModeFromFile();<br><br>2) The type of display itself is now unknowable=
.. Creating a function pointer to it will require using type deduction techn=
iques, i.e. decltype(display). Maybe this is not too bad?<br>
<br>3) We have to invent more name lookup rules at the call site. This is r=
eally hairy.<br><br>int kMode1 =3D 0;<br>display(target, 100.0, kMode1); //=
OK, should prefer function declaration scope here<br><br>But imagine this:<=
br>
<br>void display(Screen&amp; target, float ratio, enum {kMode1, kMode2} mod=
e);<br><br>display(target, x+y, kMode1);<br><br>If tomorrow the author of d=
isplay() adds a new enum value named x or y, then could he silently break t=
he caller&#39;s code? The enum name scope therefore has to be limited to ju=
st the single expression (between the commas) used to initialize the enum. =
Even there, I bet someone can concoct a more complex example which still si=
lently breaks when a name clash is introduced.<br>
<br><br></div>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/bDv6TUntNzE/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/bDv6TUntNzE=
/unsubscribe</a>.<br>

To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</blockquote></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a1133c6ce69a49c04fbfda740--

.

------=_Part_2051_29267533.1402969790838
Content-Type: text/plain; charset=UTF-8

On Monday, June 16, 2014 8:59:22 PM UTC-4, Edward Catmur wrote:
>
> I think it should be reasonably easy to come up with sensible name lookup
> rules; 3.4.2p3 would be the obvious starting point.
>
Sure, its possible there is a solution to naming.

Not being able to initialize the enum with a runtime value is killer
though. That must be addressed.

Also if you're allowing locally scoped enums, why not structs, classes, and
unions as well?

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On Monday, June 16, 2014 8:59:22 PM UTC-4, Edward Catmur w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><p dir=3D"ltr">I think it=
 should be reasonably easy to come up with sensible name lookup rules; 3.4.=
2p3 would be the obvious starting point.</p></blockquote><div>Sure, its pos=
sible there is a solution to naming.</div><div><br></div><div>Not being abl=
e to initialize the enum with a runtime value is killer though. That must b=
e addressed.</div><div><br></div><div>Also if you're allowing locally scope=
d enums, why not structs, classes, and unions as well?&nbsp;</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2051_29267533.1402969790838--

.

--Apple-Mail=_84FB5985-0791-467F-9C6F-8BACF66CDE68
Content-Type: text/plain; charset=ISO-8859-1


On 2014-06-17, at 9:49 AM, Matthew Fioravante <fmatthew5876@gmail.com> wrote:

> On Monday, June 16, 2014 8:59:22 PM UTC-4, Edward Catmur wrote:
> I think it should be reasonably easy to come up with sensible name lookup rules; 3.4.2p3 would be the obvious starting point.
>
> Sure, its possible there is a solution to naming.
>
> Not being able to initialize the enum with a runtime value is killer though. That must be addressed.
>
> Also if you're allowing locally scoped enums, why not structs, classes, and unions as well?

Structs, classes, and unions are all the same thing. And your thread "Named function parameters using anonymous structs" started eight hours ago is proposing exactly that!

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--Apple-Mail=_84FB5985-0791-467F-9C6F-8BACF66CDE68
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;06&ndash;17, at 9:49 AM, Matthew Fioravante &lt;<a href=3D"mailto:fma=
tthew5876@gmail.com">fmatthew5876@gmail.com</a>&gt; wrote:</div><br class=
=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr">O=
n Monday, June 16, 2014 8:59:22 PM UTC-4, Edward Catmur wrote:<blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
 #ccc solid;padding-left: 1ex;"><p dir=3D"ltr">I think it should be reasona=
bly easy to come up with sensible name lookup rules; 3.4.2p3 would be the o=
bvious starting point.</p></blockquote><div>Sure, its possible there is a s=
olution to naming.</div><div><br></div><div>Not being able to initialize th=
e enum with a runtime value is killer though. That must be addressed.</div>=
<div><br></div><div>Also if you're allowing locally scoped enums, why not s=
tructs, classes, and unions as well?&nbsp;</div></div></blockquote><div><br=
></div><div>Structs, classes, and unions are all the same thing. And your t=
hread "Named function parameters using anonymous structs&rdquo; started eig=
ht hours ago is proposing exactly that!</div><div><br></div></div></body></=
html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_84FB5985-0791-467F-9C6F-8BACF66CDE68--

.

------=_Part_2092_7981644.1402989215594
Content-Type: text/plain; charset=UTF-8

> Some problems with local enums:
>
> 1) When you want to construct the enum value at runtime before calling
the
> function. Making them function local essentially forces you to initialize
> the enum argument with a compile time constant.
>
> i.e. you can't do something like this:
>
> void display(Screen& target, enum { kMode1, kMode2} mode);
>
> /*What is the type??*/ mode = getDisplayModeFromFile();
> display(target, mode);
[snip]

This is exactly the situation for which this feature is NOT meant.

You are reusing the enum. 'getDisplayModeFromFile' returns the same enum as
you will put into 'display', so this is obviously a situation where you
declare your enum outside the two functions.

The local enum is meant for situations where you want named parameters that
are never used anywhere else and you do not want to pollute your namespace
with them.

Now if you start with a 'display' function that takes a local enum and
later you add 'getDisplayModeFromFile' which should share the same enum
values, than at that point you also move the local enum outside the
'display' function. As long as you don't turn it into an enum class which
requires users to prefix the names with the type name, all existing code
will continue to compile.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div class=3D"GFO--0QGHB">&gt; Some problems with local en=
ums:
<br>&gt;=20
<br>&gt; 1) When you want to construct the enum value at runtime before cal=
ling the
<br>&gt; function. Making them function local essentially forces you to ini=
tialize
<br>&gt; the enum argument with a compile time constant.
<br>&gt;=20
<br>&gt; i.e. you can't do something like this:
<br>&gt;=20
<br>&gt; void display(Screen&amp; target, enum { kMode1, kMode2} mode);
<br>&gt;=20
<br>&gt; /*What is the type??*/ mode =3D getDisplayModeFromFile();
<br>&gt; display(target, mode);
<br></div>[snip]
<br><br>This is exactly the situation for which this feature is NOT meant.<=
br><br>You are reusing the enum. 'getDisplayModeFromFile' returns the same =
enum as you will put into 'display', so this is obviously a situation where=
 you declare your enum outside the two functions.<br><br>The local enum is =
meant for situations where you want named parameters that are never used an=
ywhere else and you do not want to pollute your namespace with them.<br><br=
>Now if you start with a 'display' function that takes a local enum and lat=
er you add 'getDisplayModeFromFile' which should share the same enum values=
, than at that point you also move the local enum outside the 'display' fun=
ction. As long as you don't turn it into an enum class which requires users=
 to prefix the names with the type name, all existing code will continue to=
 compile.<br><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2092_7981644.1402989215594--

.

------=_Part_401_30524633.1403015885669
Content-Type: text/plain; charset=UTF-8



On Tuesday, June 17, 2014 3:13:35 AM UTC-4, jan.kr...@gmail.com wrote:
>
> > Some problems with local enums:
> >
> > 1) When you want to construct the enum value at runtime before calling
> the
> > function. Making them function local essentially forces you to
> initialize
> > the enum argument with a compile time constant.
> >
> > i.e. you can't do something like this:
> >
> > void display(Screen& target, enum { kMode1, kMode2} mode);
> >
> > /*What is the type??*/ mode = getDisplayModeFromFile();
> > display(target, mode);
> [snip]
>
> This is exactly the situation for which this feature is NOT meant.
>
> You are reusing the enum. 'getDisplayModeFromFile' returns the same enum
> as you will put into 'display', so this is obviously a situation where you
> declare your enum outside the two functions.
>
> The local enum is meant for situations where you want named parameters
> that are never used anywhere else and you do not want to pollute your
> namespace with them.
>

Sorry, I'm going to be a little harsh here. Who are you to dictate and
restrict how the users use your interface? All you are accomplishing with
this is a little syntactic sugar for yourself at the expense of arbitrarily
restricting what your users can do.

You may think nobody will ever want do to something, but that thinking is
always wrong. Remember, for every 10 use cases you can think of, your
clients will come up with 100 more that you didn't think about.


> Now if you start with a 'display' function that takes a local enum and
> later you add 'getDisplayModeFromFile' which should share the same enum
> values, than at that point you also move the local enum outside the
> 'display' function. As long as you don't turn it into an enum class which
> requires users to prefix the names with the type name, all existing code
> will continue to compile.
>

If the display function belongs to a third party library which I cannot
edit, then I cannot do this. I'm stuck with the faulty assumptions that the
author of the API has burdened me with. The API should remain unchanged and
expressive. If I have to keep changing the API every time my requirements
change just a little bit, then the API is a failure.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><br><br>On Tuesday, June 17, 2014 3:13:35 AM UTC-4, jan.kr=
....@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div>&gt; Some problems with local enums:
<br>&gt;=20
<br>&gt; 1) When you want to construct the enum value at runtime before cal=
ling the
<br>&gt; function. Making them function local essentially forces you to ini=
tialize
<br>&gt; the enum argument with a compile time constant.
<br>&gt;=20
<br>&gt; i.e. you can't do something like this:
<br>&gt;=20
<br>&gt; void display(Screen&amp; target, enum { kMode1, kMode2} mode);
<br>&gt;=20
<br>&gt; /*What is the type??*/ mode =3D getDisplayModeFromFile();
<br>&gt; display(target, mode);
<br></div>[snip]
<br><br>This is exactly the situation for which this feature is NOT meant.<=
br><br>You are reusing the enum. 'getDisplayModeFromFile' returns the same =
enum as you will put into 'display', so this is obviously a situation where=
 you declare your enum outside the two functions.<br><br>The local enum is =
meant for situations where you want named parameters that are never used an=
ywhere else and you do not want to pollute your namespace with them.<br></d=
iv></blockquote><div><br>Sorry, I'm going to be a little harsh here. Who ar=
e you to dictate and restrict how the users use your interface? All you are=
 accomplishing with this is a little syntactic sugar for yourself at the ex=
pense of arbitrarily restricting what your users can do. <br><br>You may th=
ink nobody will ever want do to something, but that thinking is always wron=
g. Remember, for every 10 use cases you can think of, your clients will com=
e up with 100 more that you didn't think about.<br><br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br>Now if you start with a=
 'display' function that takes a local enum and later you add 'getDisplayMo=
deFromFile' which should share the same enum values, than at that point you=
 also move the local enum outside the 'display' function. As long as you do=
n't turn it into an enum class which requires users to prefix the names wit=
h the type name, all existing code will continue to compile.<br></div></blo=
ckquote><div><br>If the display function belongs to a third party library w=
hich I cannot edit, then I cannot do this. I'm stuck with the faulty assump=
tions that the author of the API has burdened me with. The API should remai=
n unchanged and expressive. If I have to keep changing the API every time m=
y requirements change just a little bit, then the API is a failure.<br></di=
v></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_401_30524633.1403015885669--

.

------=_Part_2286_26841067.1403030921085
Content-Type: text/plain; charset=UTF-8

Matthew, please do not make this matter overly personal.

My point is that this feature idea is about situations where a full blown
enum is too much, but no enum at all is too little. I fully agree that it
is desireable to make it more powerful or more useful than what I
suggested, but most of the other suggested ways one could accomplish it
come with a lot of additional typing, which is exactly why people do not do
this with standard enums today. Therefore my goal is to get this feature in
some form that requires less typing than today already and thus helps
people to make more expressive interfaces.

The given example was a perfect case for a situation where a standard enum
is the right choice. You are correct, of course, that if it was in a
library that you cannot change, it can make your life more difficult than
if a real enum where used in the first place.

If you have a better solution, that still reduces typing and thus
accomplishes the original goal to encourage people to actually make better
interfaces, I would love to hear it. And even if not, if you want to
explore completely different ideas, sure go ahead, as others have done as
well. Something useful might come out at the end, even if it has nothing to
do with the original proposal. But please don't be offended when I do not
share your opinion.

And yes, you are right that people will use a feature in many ways that
were not anticipated, that sure makes things difficult.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">Matthew, please do not make this matter overly personal.<b=
r><br>My point is that this feature idea is about situations where a full b=
lown enum is too much, but no enum at all is too little. I fully agree that=
 it is desireable to make it more powerful or more useful than what I sugge=
sted, but most of the other suggested ways one could accomplish it come wit=
h a lot of additional typing, which is exactly why people do not do this wi=
th standard enums today. Therefore my goal is to get this feature in some f=
orm that requires less typing than today already and thus helps people to m=
ake more expressive interfaces.<br><br>The given example was a perfect case=
 for a situation where a standard enum is the right choice. You are correct=
, of course, that if it was in a library that you cannot change, it can mak=
e your life more difficult than if a real enum where used in the first plac=
e.<br><br>If you have a better solution, that still reduces typing and thus=
 accomplishes the original goal to encourage people to actually make better=
 interfaces, I would love to hear it. And even if not, if you want to explo=
re completely different ideas, sure go ahead, as others have done as well. =
Something useful might come out at the end, even if it has nothing to do wi=
th the original proposal. But please don't be offended when I do not share =
your opinion.<br><br>And yes, you are right that people will use a feature =
in many ways that were not anticipated, that sure makes things difficult.<b=
r></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2286_26841067.1403030921085--

.