Topic: Function local enums for easier writing of
Author: Johannes Schaub <schaub.johannes@googlemail.com>
Date: Tue, 10 Jun 2014 22:38:45 +0200
Raw View
2014-06-10 22:34 GMT+02:00 Matthew Woehlke <mw_triad@users.sourceforge.net>:
> 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);
>
This is a heavy change in interface and includes much boilerplate
code. BTW, the code creates a default constructed "DeleteFiles"
variable called "mode".
--
---
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/.
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Tue, 10 Jun 2014 13:43:02 -0700
Raw View
--001a11337e42c286c404fb815f20
Content-Type: text/plain; charset=UTF-8
On Tue, Jun 10, 2014 at 1:38 PM, Johannes Schaub <
schaub.johannes@googlemail.com> wrote:
> 2014-06-10 22:34 GMT+02:00 Matthew Woehlke <mw_triad@users.sourceforge.net
> >:
> > 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);
> >
>
> This is a heavy change in interface and includes much boilerplate
> code. BTW, the code creates a default constructed "DeleteFiles"
> variable called "mode".
I assume this was meant to be
static struct DeleteFile { /* ... */ } <ins>DeleteFile</ins>;
--
---
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/.
--001a11337e42c286c404fb815f20
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Jun 10, 2014 at 1:38 PM, Johannes Schaub <span dir=3D"ltr"><<a href=
=3D"mailto:schaub.johannes@googlemail.com" target=3D"_blank">schaub.johanne=
s@googlemail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">2014-06-10 22:34 GMT+02:00 Matthew Woehlke &=
lt;<a href=3D"mailto:mw_triad@users.sourceforge.net">mw_triad@users.sourcef=
orge.net</a>>:<br>
<div class=3D"">> On 2014-06-10 15:12, <a href=3D"mailto:jan.krassnigg@g=
mail.com">jan.krassnigg@gmail.com</a> wrote:<br>
>> // BEST (IMO):<br>
>><br>
>> =C2=A0 void DeleteFile(enum{Recursive, NonRecursive} option);<br>
>> =C2=A0 DeleteFile(Recursive); // clear, quick to type, not reusabl=
e outside of<br>
>> DeleteFile, cannot conflict with other type names<br>
>> =C2=A0 // if there is another enum or variable with the same name,=
the function<br>
>> enum value takes precedence<br>
><br>
> =C2=A0 static struct DeleteFile<br>
> =C2=A0 {<br>
> =C2=A0 =C2=A0 enum class Option<br>
> =C2=A0 =C2=A0 {<br>
> =C2=A0 =C2=A0 =C2=A0 Recursive,<br>
> =C2=A0 =C2=A0 =C2=A0 ...<br>
> =C2=A0 =C2=A0 };<br>
> =C2=A0 =C2=A0 using enum Option;<br>
><br>
> =C2=A0 =C2=A0 operator()(Option) {...}<br>
> =C2=A0 };<br>
><br>
> =C2=A0 auto mode =3D DeleteFiles::Recursive<br>
> =C2=A0 DeleteFiles(mode);<br>
><br>
<br>
</div>This is a heavy change in interface and includes much boilerplate<br>
code. BTW, the code creates a default constructed "DeleteFiles"<b=
r>
variable called "mode".</blockquote><div><br></div><div>I assume =
this was meant to be</div><div><br></div><div>=C2=A0 static struct DeleteFi=
le { /* ... */ } <ins>DeleteFile</ins>;=C2=A0</div></div></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" 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 />
--001a11337e42c286c404fb815f20--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 10 Jun 2014 23:46:15 +0300
Raw View
On 10 June 2014 23:18, <jan.krassnigg@gmail.com> wrote:
>> 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.
Do you think such enums are common enough for a core language change?
I don't.
> 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
Yes, if I have to have some additional scoping for it. Or I would put
these further-scoped
parameter types/enums in a nested namespace.
At the risk of a slight digression, it's possible to use function-local types
outside a function, but such types can't be used as parameters of the function:
auto deleteFile()
{
enum oink {FIRST, SECOND, THIRD};
return oink{};
}
int main()
{
decltype(deleteFile()) a = decltype(deleteFile())::FIRST;
}
--
---
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/.
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Tue, 10 Jun 2014 16:02:09 -0700
Raw View
--001a11c1c27240d65f04fb835175
Content-Type: text/plain; charset=UTF-8
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?
> ("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/.
>
--
---
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/.
--001a11c1c27240d65f04fb835175
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Jun 10, 2014 at 2:29 PM, Matthew Woehlke <span dir=3D"ltr"><<a href=
=3D"mailto:mw_triad@users.sourceforge.net" target=3D"_blank">mw_triad@users=
..sourceforge.net</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">On 2014-06-10 16:43, Richard Smith wrote:<br=
>
<div class=3D"">> On Tue, Jun 10, 2014 at 1:38 PM, Johannes Schaub wrote=
:<br>
>> 2014-06-10 22:34 GMT+02:00 Matthew Woehlke wrote:<br>
>>> =C2=A0 static struct DeleteFile<br>
>>> =C2=A0 {<br>
>>> =C2=A0 =C2=A0 enum class Option<br>
>>> =C2=A0 =C2=A0 {<br>
>>> =C2=A0 =C2=A0 =C2=A0 Recursive,<br>
>>> =C2=A0 =C2=A0 =C2=A0 ...<br>
>>> =C2=A0 =C2=A0 };<br>
>>> =C2=A0 =C2=A0 using enum Option;<br>
>>><br>
>>> =C2=A0 =C2=A0 operator()(Option) {...}<br>
>>> =C2=A0 };<br>
>>><br>
>>> =C2=A0 auto mode =3D DeleteFiles::Recursive<br>
>>> =C2=A0 DeleteFiles(mode);<br>
>><br>
>> This is a heavy change in interface and includes much boilerplate<=
br>
>> code.<br>
<br>
</div>True. OTOH you can do all sorts of things with this (e.g. "funct=
ion"<br>
local types, static variables, etc.) that you couldn't do with the<br>
original proposal. And the changes to the compiler are less; don't allo=
w<br>
construction, and treat 'T()' as invoking the operator() rather tha=
n<br>
construction. (And 'using enum' and changes to scope lookup rules, =
but<br>
the former is independently desirable, and the latter is required<br>
regardless.) Compare to allowing definitions of enums inside of a<br>
parameter list. (And how would you provide a separate definition of a<br>
function given the original proposal? Specify that the enum *must* be<br>
nameless and is considered a type specifier?)<br>
<br>
And really, how much overhead is it? We have "static struct", &qu=
ot;{",<br>
"using", "Option", "operator()", and "};=
". The rest is there in the<br>
original proposal as well. (Note: I assumed a further refinement to<br>
allow "using" to apply to the definition of the enum.)<br>
<div class=3D""><br>
>> BTW, the code creates a default constructed "DeleteFiles"=
;<br>
>> variable called "mode".<br>
<br>
</div>Huh? How do you figure that? (Especially since DeleteFiles is not<br>
constructable...)<br>
<br>
'DeleteFiles::Recursive' names an enum value. Assigning to an auto<=
br>
variable 'mode' declares 'mode' to be of the enum type with=
the named<br>
value. I see no construction of the enclosing scope object.<br>
<div class=3D""><br>
> I assume this was meant to be<br>
><br>
> =C2=A0 static struct DeleteFile { /* ... */ } <ins>DeleteFile<=
;/ins>;<br>
<br>
</div>Ah... no? In fact that wouldn't be legal.</blockquote><div><br></=
div><div>Huh? That is legal C++ already, and does exactly what you wanted, =
no?</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
("static struct" is maybe not<br>
the best way to designate the scope. I picked it because it uses only<br>
existing keywords, but I see where the compiler differentiating a<br>
definition versus a declaration could be tricky. But that's mostly<br>
bikeshedding.)<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Matthew<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@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/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><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" 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 />
--001a11c1c27240d65f04fb835175--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 11 Jun 2014 11:50:38 -0400
Raw View
--e89a8f3ba0ff5afcbf04fb916ad2
Content-Type: text/plain; charset=UTF-8
On 10 June 2014 16:46, Ville Voutilainen <ville.voutilainen@gmail.com>
wrote:
> Do you think such enums are common enough for a core language change?
> I don't.
>
I disagree. I believe the use case is fairly common, and that to avoid
adding yet another type people fall back either using non-descriptive
bools, ints, etc,, or (worse) reusing an existing enum for a purpose it
wasn't designed for.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
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/.
--e89a8f3ba0ff5afcbf04fb916ad2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 10 June 2014 16:46, Ville Voutilainen <span dir=3D"ltr"=
><<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville=
..voutilainen@gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra">=
<div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">Do you think such enums are =
common enough for a core language change?<br></div>
I don't.<br></blockquote><div><br></div><div>I disagree. =C2=A0I believ=
e the use case is fairly common, and that to avoid adding yet another type =
people fall back either using non-descriptive bools, ints, etc,, or (worse)=
reusing an existing enum for a purpose it wasn't designed for.=C2=A0</=
div>
</div>-- <br>=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
>=C2=A0 (847) 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" 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 />
--e89a8f3ba0ff5afcbf04fb916ad2--
.
Author: Zhihao Yuan <zy@miator.net>
Date: Wed, 11 Jun 2014 11:58:12 -0400
Raw View
On Wed, Jun 11, 2014 at 11:50 AM, Nevin Liber <nevin@eviloverlord.com> wrote:
>
> I disagree. I believe the use case is fairly common, and that to avoid
> adding yet another type people fall back either using non-descriptive bools,
> ints, etc,, or (worse) reusing an existing enum for a purpose it wasn't
> designed for.
Example:
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4007.htm
Just for 1 function, this paper defines
enum delimiter_type {
infix,
suffix
};
So some kinds of symbolic parameters do help.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://bit.ly/blog4bsd
--
---
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/.
.
Author: Edward Catmur <ed@catmur.co.uk>
Date: Wed, 11 Jun 2014 09:57:44 -0700 (PDT)
Raw View
------=_Part_298_32754556.1402505864558
Content-Type: text/plain; charset=UTF-8
On Wednesday, 11 June 2014 16:58:21 UTC+1, Zhihao Yuan wrote:
>
> Example:
>
> http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4007.htm
>
> Just for 1 function, this paper defines
>
> enum delimiter_type {
> infix,
> suffix
> };
>
> So some kinds of symbolic parameters do help.
>
Suppose ADL *[basic.lookup.argdep]* were extended to apply also to the
elements of the function call *expression-list* where the
*initializer-clause* is an *unqualified-id*. Then we could write:
namespace outer {
namespace inner {
enum style { somehow, contrariwise };
}
void do_something(inner::style);
}
outer::do_something(contrariwise); // argument ADL!
I suppose this might make some existing code ambiguous, though not much I'd
imagine. It would be possible as now to suppress argument ADL with
parentheses.
--
---
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_298_32754556.1402505864558
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, 11 June 2014 16:58:21 UTC+1, Zhihao Yuan wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">Example:
<br>
<br><a href=3D"http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n400=
7.htm" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/=
url?q\75http%3A%2F%2Fwww.open-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%=
2F2014%2Fn4007.htm\46sa\75D\46sntz\0751\46usg\75AFQjCNFI3tyeS8quiiLCPYGwgfH=
Ro1xDUw';return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\=
75http%3A%2F%2Fwww.open-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2014=
%2Fn4007.htm\46sa\75D\46sntz\0751\46usg\75AFQjCNFI3tyeS8quiiLCPYGwgfHRo1xDU=
w';return true;">http://www.open-std.org/JTC1/<wbr>SC22/WG21/docs/papers/20=
14/<wbr>n4007.htm</a>
<br>
<br>Just for 1 function, this paper defines
<br>
<br> enum delimiter_type {
<br> infix,
<br> suffix
<br> };
<br>
<br>So some kinds of symbolic parameters do help.
<br></blockquote><div><br></div><div><span style=3D"font-family: arial; fon=
t-size: small;">Suppose ADL <b>[basic.lookup.argdep]</b> were extended to a=
pply also to the elements of the function call <i>expression-list</i> =
where the <i>initializer-clause</i> is an <i>unqualified-id</i>. Then we co=
uld write:</span><div style=3D"font-family: arial; font-size: small;"><br><=
/div><div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 18=
7); word-wrap: break-word; background-color: rgb(250, 250, 250);"><code cla=
ss=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008=
;" class=3D"styled-by-prettify">namespace</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> outer </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></span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">namespace</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> inner </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">enum</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> style </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> somehow</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> contrariwise </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></span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">void</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> do_something</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">inner</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">style</spa=
n><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><br>outer</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">do_something</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">contrariwise</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"styled-by-prettify">// argument ADL!</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"><br></span></div></code></div><div style=3D"f=
ont-family: arial; font-size: small;"><br></div></div><div style=3D"font-fa=
mily: arial; font-size: small;">I suppose this might make some existing cod=
e ambiguous, though not much I'd imagine. It would be possible as now to su=
ppress argument ADL with parentheses.</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" 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_298_32754556.1402505864558--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 11 Jun 2014 23:41:09 -0500
Raw View
--e89a8f3ba0ffd5a03904fb9c2d56
Content-Type: text/plain; charset=UTF-8
On 11 June 2014 17:09, <jan.krassnigg@gmail.com> wrote:
>
> 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).
>
Oh, I would be strongly against something like that. If it says "enum" or
"enum class", it needs to behave like enums and enum classes, and not a
completely different set of rules.
This should be a simple mechanism.
Enums are different types than ints. If you want to allow ints to be
passed as well as enums, make another function overload.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
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/.
--e89a8f3ba0ffd5a03904fb9c2d56
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 11 June 2014 17:09, <span dir=3D"ltr"><<a href=3D"m=
ailto:jan.krassnigg@gmail.com" target=3D"_blank">jan.krassnigg@gmail.com</a=
>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote=
"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D""><br><blockquote style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"g=
mail_quote"><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><di=
v><br>Actually the way I envisioned it is that the parameter is simply alwa=
ys an int, but that the enum part is like an "annotation" (or wha=
tever you'd want to call it).<br>
</div></div></blockquote><div><br></div><div>Oh, I would be strongly agains=
t something like that. =C2=A0If it says "enum" or "enum clas=
s", it needs to behave like enums and enum classes, and not a complete=
ly different set of rules.</div>
<div><br></div><div>This should be a simple mechanism.</div><div><br></div>=
<div>Enums are different types than ints. =C2=A0If you want to allow ints t=
o be passed as well as enums, make another function overload.</div><div>--=
=C2=A0<br>
</div></div>=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a href=3D"m=
ailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&=
gt;=C2=A0 (847) 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" 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 />
--e89a8f3ba0ffd5a03904fb9c2d56--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 11 Jun 2014 23:43:44 -0500
Raw View
--e89a8f3ba0ff1e1a0e04fb9c376d
Content-Type: text/plain; charset=UTF-8
On 11 June 2014 18:03, Matthew Woehlke <mw_triad@users.sourceforge.net>
wrote:
> (Hmm... 'auto'? Should we (in general) allow the type of a function
> parameter to be 'auto' if the function has been previously defined?
No. It should not have a different meaning here than in lambdas.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
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/.
--e89a8f3ba0ff1e1a0e04fb9c376d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 11 June 2014 18:03, Matthew Woehlke <span dir=3D"ltr">&=
lt;<a href=3D"mailto:mw_triad@users.sourceforge.net" target=3D"_blank">mw_t=
riad@users.sourceforge.net</a>></span> wrote:<br><div class=3D"gmail_ext=
ra"><div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">(Hmm... 'auto'? Shou=
ld we (in general) allow the type of a function<br></div>
parameter to be 'auto' if the function has been previously defined?=
</blockquote><div><br></div><div>No. =C2=A0It should not have a different m=
eaning here than in lambdas.</div></div>-- <br>=C2=A0Nevin ":-)" =
Liber=C2=A0 <mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"=
_blank">nevin@eviloverlord.com</a>>=C2=A0 (847) 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" 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 />
--e89a8f3ba0ff1e1a0e04fb9c376d--
.
Author: David Krauss <potswa@gmail.com>
Date: Fri, 13 Jun 2014 01:47:51 +0800
Raw View
--Apple-Mail=_0106F240-DA78-431F-A207-72F0047B48B9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-06-13, at 12:00 AM, Matthew Woehlke <mw_triad@users.sourceforge.net=
> wrote:
> On 2014-06-12 01:42, David Krauss wrote:
>> On 2014-06-11, 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't like this: qualifying the function arguments with the function n=
ame puts=20
>> an excessive cost on long function names, and leads to repetition anyway=
..
>=20
> I think the point here is that they can be looked up *outside* of the
> function argument list, which I think is important.
>=20
> Within the function argument list, we want the function scope to be used
> for lookup.
>=20
> IOW, both of these are legal:
>=20
> auto mode =3D DeleteFiles::Recursive; // named outside of call
> DeleteFiles(mode);
>=20
> DeleteFiles(Recursive); // no need to repeat scope when part of call
It's certainly a use-case, but I think the feature is mainly applicable whe=
n it's anticipated with some certainty that the user will not be calculatin=
g the argument. If the user declares a named variable, it might as well be =
called recursiveness and then the problem has already gone away. The origin=
al problem is simply that it's too easy to pass true or false and be done w=
ith it.
If the call can go either way, DeleteFiles( recurse? recursive : non_recurs=
ive ) might be a reasonable form. This is an exception to my "no operators"=
rule, but still not too complicated.
>> 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
>> );
>=20
> 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.)
Yep. If it's fixed in the general case, then it will be fixed here too. But=
it's another battle.
>> // use
>> DeleteFile( recursive, force );
>=20
> Wait... how come *here* you don't need to qualify the enum values?
Same as your reason. The call is used to produce lookup context, to avoid r=
epetition.
--=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=_0106F240-DA78-431F-A207-72F0047B48B9
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–13, at 12:00 AM, Matthew Woehlke <<a href=3D"mailto:mw_tr=
iad@users.sourceforge.net">mw_triad@users.sourceforge.net</a>> wrote:</d=
iv><br class=3D"Apple-interchange-newline"><blockquote type=3D"cite">On 201=
4-06-12 01:42, David Krauss wrote:<br><blockquote type=3D"cite">On 2014&nda=
sh;06–11, at 3:33 AM, Andrew Tomazos wrote:<br><blockquote type=3D"ci=
te">Names can be introduced into the function name scope of a function F by=
syntax <br>in the declarations of the function F. A name N in functi=
on name scope can be <br>looked up with qualified lookup on the function na=
me F::N<br></blockquote><br>I don’t like this: qualifying the functio=
n arguments with the function name puts <br>an excessive cost on long funct=
ion names, and leads to repetition anyway.<br></blockquote><br>I think the =
point here is that they can be looked up *outside* of the<br>function argum=
ent list, which I think is important.<br><br>Within the function argument l=
ist, we want the function scope to be used<br>for lookup.<br><br>IOW, both =
of these are legal:<br><br> auto mode =3D DeleteFiles::Recursive; // =
named outside of call<br> DeleteFiles(mode);<br><br> DeleteFile=
s(Recursive); // no need to repeat scope when part of call<br></blockquote>=
<div><br></div><div>It’s certainly a use-case, but I think the featur=
e is mainly applicable when it’s anticipated with some certainty that=
the user will not be calculating the argument. If the user declares a name=
d variable, it might as well be called <font face=3D"Courier">recursiveness=
</font> and then the problem has already gone away. The original problem is=
simply that it’s too easy to pass <font face=3D"Courier">true</font>=
or <font face=3D"Courier">false</font> and be done with it.</div><div><br>=
</div><div>If the call can go either way, <font face=3D"Courier">DeleteFile=
s( recurse? recursive : non_recursive )</font> might be a reasonable form. =
This is an exception to my “no operators” rule, but still not t=
oo complicated.</div><br><blockquote type=3D"cite"><blockquote type=3D"cite=
">So it could all look like this:<br><br>// prototype<br>void DeleteFile(<b=
r> enum class recurse_opt { recursive, nonrecursive=
} =3D recurse_opt::nonrecursive,<br> enum class fo=
rce_opt { force, careful } =3D force_opt::careful<br>);<br></blockquote><br=
>I'd argue that in this case one shouldn't need to repeat the enum name<br>=
to qualify the enum value. (Of course, that's a problem with enum class<br>=
in general, as I've mentioned previously.)<br></blockquote><div><br></div><=
div>Yep. If it’s fixed in the general case, then it will be fixed her=
e too. But it’s another battle.</div><br><blockquote type=3D"cite"><b=
lockquote type=3D"cite">// use<br>DeleteFile( recursive, force );<br></bloc=
kquote><br>Wait... how come *here* you don't need to qualify the enum value=
s?<br></blockquote><div><br></div>Same as your reason. The call is used to =
produce lookup context, to avoid repetition.</div><div><br></div></body></h=
tml>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+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=_0106F240-DA78-431F-A207-72F0047B48B9--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 12 Jun 2014 18:37:20 -0700
Raw View
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 enum=
class =20
>=20
> // =E2=80=A6 =20
> } =20
That is already allowed today. We can't break it.
--=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/.
.
Author: David Krauss <potswa@gmail.com>
Date: Fri, 13 Jun 2014 11:08:33 +0800
Raw View
--Apple-Mail=_AFD59D84-D9B7-47DE-B4CD-DEEEEA6B5C10
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-06-13, at 2:14 AM, Matthew Woehlke <mw_triad@users.sourceforge.net>=
wrote:
> 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);
>>>=20
>>> 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 =
when it's anticipated with some certainty that the user will not be calcula=
ting the argument. If the user declares a named variable, it might as well =
be called recursiveness and then the problem has already gone away. The ori=
ginal problem is simply that it's too easy to pass true or false and be don=
e with it.
>>=20
>> If the call can go either way, DeleteFiles( recurse? recursive : non_rec=
ursive ) might be a reasonable form. This is an exception to my "no operato=
rs" rule, but still not too complicated.
>=20
> Where I see this going entirely sideways is if the parameter is a flags
> (or even multiple choice) rather than better-named true/false.
Perhaps so. Our ideas may be compatible; nothing I said precludes allowing =
qualification by the function name as well.
> function DeleteFiles
> {
> using enum class recurse_opt { recursive, nonrecursive };
> const default_recurse =3D nonrecursive;
> operator()(recurse_opt =3D default_recurse);
> };
You might as well just define a functor class. Seems to be where this is ge=
nerally heading.
> ...except 'recursive' is still not in scope, in this example. It would
> still need to be 'recurse_opt::recursive'.
My proposal does not place recurse_opt in scope. If it were in scope, you c=
ould use the enumeration name to form a cast expression.
> (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.
Note, if all you want is to have the nested-name-specifier match the functi=
on 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 =3D false, recursive,
careful =3D false, force
};
void DeleteFiles( enum DeleteFiles, enum DeleteFiles ) {
}
DeleteFiles( DeleteFiles::nonrecursive, DeleteFiles::force );
GCC rejects this for whatever reason, but it's valid and accepted by Clang.
> 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?)
Yes, I explained it in my initial post. Lookup inside an argument for a fun=
ction-scope enumeration parameter would consider the enumerators. Perhaps n=
on-function-scope enumerator types, and all initializers of scoped enumerat=
ion objects, should get the same treatment; this would handily solve the te=
ndency to excessive repetition of scoped enumeration names.
However, the implementation effort is probably significant.
--=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=_AFD59D84-D9B7-47DE-B4CD-DEEEEA6B5C10
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–13, at 2:14 AM, Matthew Woehlke <<a href=3D"mailto:mw_tri=
ad@users.sourceforge.net">mw_triad@users.sourceforge.net</a>> wrote:</di=
v><br class=3D"Apple-interchange-newline"><blockquote type=3D"cite">On 2014=
-06-12 13:47, David Krauss wrote:<br><blockquote type=3D"cite">On 2014-06-1=
3, at 12:00 AM, Matthew Woehlke wrote:<br><blockquote type=3D"cite"> auto m=
ode =3D DeleteFiles::Recursive; // named outside of call<br> DeleteFiles(mo=
de);<br><br> DeleteFiles(Recursive); // no need to repeat scope when part o=
f call<br></blockquote><br>It's certainly a use-case, but I think the featu=
re is mainly applicable when it's anticipated with some certainty that the =
user will not be calculating the argument. If the user declares a named var=
iable, it might as well be called recursiveness and then the problem has al=
ready gone away. The original problem is simply that it's too easy to pass =
true or false and be done with it.<br><br>If the call can go either way, De=
leteFiles( recurse? recursive : non_recursive ) might be a reasonable form.=
This is an exception to my "no operators" rule, but still not too complica=
ted.<br></blockquote><br>Where I see this going entirely sideways is if the=
parameter is a flags<br>(or even multiple choice) rather than better-named=
true/false.<br></blockquote><div><br></div><div>Perhaps so. Our ideas may =
be compatible; nothing I said precludes allowing qualification by the funct=
ion name as well.</div><br><blockquote type=3D"cite"> function DeleteF=
iles<br> {<br> using enum class recurse_opt { recur=
sive, nonrecursive };<br> const default_recurse =3D nonre=
cursive;<br> operator()(recurse_opt =3D default_recurse);=
<br> };<br></blockquote><div><br></div><div>You might as well just de=
fine a functor class. Seems to be where this is generally heading.</div><br=
><blockquote type=3D"cite">...except 'recursive' is still not in scope, in =
this example. It would<br>still need to be 'recurse_opt::recursive’. =
</blockquote><div><br></div><div>My proposal does not place <font face=3D"C=
ourier">recurse_opt</font> in scope. If it were in scope, you could use the=
enumeration name to form a cast expression.</div><br><blockquote type=3D"c=
ite">(The "right" solution of<br>course is for the parent scope to inherit =
the enum values, as otherwise<br>stated. </blockquote><div><br></div><div>T=
hen you might as well declare enumeration in the function’s parent sc=
ope. That’s the current practice.</div><div><br></div><div>Note, if a=
ll you want is to have the nested-name-specifier match the function name, y=
ou can already do that because enumerations can alias functions, but functi=
ons are ignored by lookup from a nested-name-specifier.</div><div><br></div=
><div><font face=3D"Courier">enum class DeleteFiles : bool {</font></div><d=
iv><font face=3D"Courier"> nonrecursive =3D false, recursive,<=
/font></div><div><font face=3D"Courier"> careful =3D false, fo=
rce</font></div><div><font face=3D"Courier">};</font></div><div><font face=
=3D"Courier"><br></font></div><div><font face=3D"Courier">void DeleteFiles(=
enum DeleteFiles, enum DeleteFiles ) {</font></div><div><font face=3D"Cour=
ier">}</font></div><div><font face=3D"Courier"><br></font></div><div><font =
face=3D"Courier">DeleteFiles( DeleteFiles::nonrecursive, DeleteFiles::force=
);</font></div><div><br></div><div>GCC rejects this for whatever reason, b=
ut it’s valid and accepted by Clang.</div><br><blockquote type=3D"cit=
e">I was pointing out the inconsistency in order to seek<br>clarification; =
was this an oversight, or did you intend that the lookup<br>rules should wo=
rk differently in this context?)<br></blockquote><div><br></div></div>Yes, =
I explained it in my initial post. Lookup inside an argument for a function=
-scope enumeration parameter would consider the enumerators. Perhaps non-fu=
nction-scope enumerator types, and all initializers of scoped enumeration o=
bjects, should get the same treatment; this would handily solve the tendenc=
y to excessive repetition of scoped enumeration names.<div><br></div><div>H=
owever, the implementation effort is probably significant.</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" 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=_AFD59D84-D9B7-47DE-B4CD-DEEEEA6B5C10--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 13 Jun 2014 12:22:47 -0700
Raw View
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
> >> }
> >=20
> > That is already allowed today. We can't break it.
>=20
> 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 f=
rom =E2=80=98option=E2=80=99 to
> =E2=80=98int=E2=80=99" (also "from =E2=80=98int=E2=80=99 to =E2=80=98opti=
on=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.
Sorry, I missed the "class" in the original declaration.
--=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/.
.
Author: David Krauss <potswa@gmail.com>
Date: Sat, 14 Jun 2014 09:53:08 +0800
Raw View
--Apple-Mail=_C0EA4494-58DA-4537-893A-3A7CF3BA7BA1
Content-Type: text/plain; charset=ISO-8859-1
On 2014-06-14, at 12:11 AM, Matthew Woehlke <mw_triad@users.sourceforge.net> wrote:
> 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'.
Self-instantiating functors will be covered by my inline variables proposal. Hopefully it finds support; I should continue working on the write-up.
struct DeleteFiles
{
enum class recurse_opt { recursive, nonrecursive };
recurse_opt const default_recurse = recurse_opt::nonrecursive;
void operator()(recurse_opt = recurse_opt::default_recurse);
} inline DeleteFiles; // The id-expression "DeleteFiles" default-constructs a new functor.
>> 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.
Right, that's the critical part.
>> 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.)
The user shouldn't be locked-into the function-scope enumeration. Migration to namespace scope ideally shouldn't sacrifice call syntax.
Pollution should be avoided, as long as strong scoping is disabled only within initializations of the given enumeration. Only that one is selectively de-scoped, whether it's function-specific or not.
Unfortunately, the interaction with overload resolution leads to a complexity explosion, albeit a small one, in the argument passing use-case.
> 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.
This sounds again a lot like the functor style implementation, but with unscoped member enumerations. (It would be nice to disable integer conversions on unscoped enumerations... maybe with strong typedefs...)
>> 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 :-).
Yes, but syntactically close enough to get the feel of the style. Only if the syntax is nice enough should we spend effort cleaning up the semantics.
--
---
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=_C0EA4494-58DA-4537-893A-3A7CF3BA7BA1
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–14, at 12:11 AM, Matthew Woehlke <<a href=3D"mailto:mw_tr=
iad@users.sourceforge.net">mw_triad@users.sourceforge.net</a>> wrote:</d=
iv><br class=3D"Apple-interchange-newline"><blockquote type=3D"cite">On 201=
4-06-12 23:08, David Krauss wrote:<br><blockquote type=3D"cite">On 2014-06-=
13, at 2:14 AM, Matthew Woehlke wrote:<br><blockquote type=3D"cite"> functi=
on DeleteFiles<br> {<br> using enum class recurse_opt { recursi=
ve, nonrecursive };<br> const default_recurse =3D nonrecursive;=
<br> operator()(recurse_opt =3D default_recurse);<br> };<br></b=
lockquote><br>You might as well just define a functor class. Seems to be wh=
ere this is generally heading.<br></blockquote><br>Yes, that's essentially =
the idea. The key difference is that there is no<br>instantiation of the 'f=
unction' as an object, as there would be with a<br>'true functor class&rsqu=
o;.<br></blockquote><div><br></div><div>Self-instantiating functors will be=
covered by my inline variables proposal. Hopefully it finds support; I sho=
uld continue working on the write-up.</div><div><br></div><div><font face=
=3D"Courier">struct DeleteFiles</font></div><div><font face=3D"Courier">{</=
font></div><div><font face=3D"Courier"> enum class recurse_opt { recu=
rsive, nonrecursive };<br> </font><span style=3D"font-family: Co=
urier;">recurse_opt</span> <span style=3D"font-family: Courier;"=
>const default_recurse =3D recurse_opt::nonrecursive;</span></div><div><fon=
t face=3D"Courier"><br></font></div><div><font face=3D"Courier"> void=
operator()(recurse_opt =3D </font><span style=3D"font-family: Courier=
;">recurse_opt::</span><span style=3D"font-family: Courier;">default_recurs=
e);</span></div><div><font face=3D"Courier"><br></font></div><div><font fac=
e=3D"Courier">} inline DeleteFiles; // The id-expression “DeleteFiles=
” default-constructs a new functor.</font></div><div><br></div><div><=
br></div><blockquote type=3D"cite"><blockquote type=3D"cite">Yes, I explain=
ed it in my initial post. Lookup inside an argument for<br>a function-scope=
enumeration parameter would consider the<br>enumerators.<br></blockquote><=
br>Ah, that's what I missed. Hmm... I guess I can live with it, although I<=
br>would suggest that only those enumerations are considered which are the<=
br>type of the parameter for which lookup is being performed.<br></blockquo=
te><div><br></div><div>Right, that’s the critical part.</div><br><blo=
ckquote type=3D"cite"><blockquote type=3D"cite">Perhaps non-function-scope =
enumerator types<br></blockquote><br>I don't think this should be done as a=
general rule. Given a bunch of<br>'enum class's in a large namespace, this=
would lead to pollution of the<br>parent namespace and the same problems w=
e had before enum class. (As you<br>undoubtedly know from how many times I'=
ve said it before, I do think we<br>need the ability to selectively turn of=
f strong scoping, though.)<br></blockquote><div><br></div><div>The user sho=
uldn’t be locked-into the function-scope enumeration. Migration to na=
mespace scope ideally shouldn’t sacrifice call syntax.</div><div><br>=
</div><div>Pollution should be avoided, as long as strong scoping is disabl=
ed only within initializations of the given enumeration. Only that one is s=
electively de-scoped, whether it’s function-specific or not.</div><di=
v><br></div><div>Unfortunately, the interaction with overload resolution le=
ads to a complexity explosion, albeit a small one, in the argument passing =
use-case.</div><br><blockquote type=3D"cite">No; the point is to allow enum=
*class* members to be named from their<br>parent scope (the function). IOW=
, "DeleteFiles::recursive" instead of<br>"DeleteFiles::recursive_opt::recur=
sive". Per your rules above this<br>wouldn't apply to parameters (which is =
perhaps where our communication<br>is breaking down), but to naming the val=
ues outside of a call of the<br>function.<br></blockquote><div><br></div><d=
iv>This sounds again a lot like the functor style implementation, but with =
unscoped member enumerations. (It would be nice to disable integer conversi=
ons on unscoped enumerations… maybe with strong typedefs…)</d=
iv><br><blockquote type=3D"cite"><blockquote type=3D"cite">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 ar=
e ignored by lookup from a nested-name-specifier.<br><br>enum class DeleteF=
iles : bool {<br> nonrecursive =3D false, recursive,<br> =
careful =3D false, force<br>};<br><br>void DeleteFiles( e=
num DeleteFiles, enum DeleteFiles ) {<br>}<br></blockquote><br>I think this=
speaks for itself why it is inadequate :-).<br></blockquote><div><br></div=
></div>Yes, but syntactically close enough to get the feel of the style. On=
ly if the syntax is nice enough should we spend effort cleaning up the sema=
ntics.<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" 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=_C0EA4494-58DA-4537-893A-3A7CF3BA7BA1--
.