------=_Part_617_10577749.1402866064613
Content-Type: text/plain; charset=UTF-8

I agree anonymous structs would be a great feature.

Would there be less risk of ambiguous parses if the designated initialiser
syntax of C was taken  - and would that make it easier to retrofit into C?

display(screen, { .yres=480, .xres=640});

--

---
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_617_10577749.1402866064613
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I agree anonymous structs would be a great feature.</=
div><div><br></div>Would there be less risk of ambiguous parses if the desi=
gnated initialiser syntax of C was taken &nbsp;- and would that make it eas=
ier to retrofit into C?<div><br></div><div><div>display(screen, { .yres=3D4=
80, .xres=3D640});</div></div><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&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_617_10577749.1402866064613--

.

------=_Part_623_18232830.1402866383676
Content-Type: text/plain; charset=UTF-8

I agree anonymous structs would be a great feature.

[1] Would there be less risk of ambiguous parses if the designated
initialiser syntax of C was taken  - and would that make it easier to
retrofit into C?

  void display(Screen& target, struct { int xres, int yres/*, etc..*/ });
//<- compiler generated anonymous struct type

  display(screen, { .yres=480, .xres=640});

[2] Would it also be a good way of doing multiple return values. Might
actually be more pleasant than tuples in other languages.

   auto do_something()-> struct { int x; int y  }

[3] could it work with auto...

   auto do_something() {
       return {.x=..., .y=....}
   }

--

---
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_623_18232830.1402866383676
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I agree anonymous structs would be a great feature.</=
div><div><br></div>[1] Would there be less risk of ambiguous parses if the =
designated initialiser syntax of C was taken &nbsp;- and would that make it=
 easier to retrofit into C?&nbsp;<div><br></div><div><div>&nbsp; void displ=
ay(Screen&amp; target, struct { int xres, int yres/*, etc..*/ }); //&lt;- c=
ompiler generated anonymous struct type</div><div><br></div><div>&nbsp; dis=
play(screen, { .yres=3D480, .xres=3D640});</div><div><br></div><div>[2] Wou=
ld it also be a good way of doing multiple return values. Might actually be=
 more pleasant than tuples in other languages.</div><div><br></div><div>&nb=
sp; &nbsp;auto do_something()-&gt; struct { int x; int y &nbsp;}</div></div=
><div><br></div><div>[3] could it work with auto...</div><div><br></div><di=
v>&nbsp; &nbsp;auto do_something() {</div><div>&nbsp; &nbsp; &nbsp; &nbsp;r=
eturn {.x=3D..., .y=3D....}</div><div>&nbsp; &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_623_18232830.1402866383676--

.

------=_Part_372_27833215.1402946332233
Content-Type: text/plain; charset=UTF-8



On Sunday, June 15, 2014 5:06:23 PM UTC-4, walter1234 wrote:
>
> I agree anonymous structs would be a great feature.
>
> [1] Would there be less risk of ambiguous parses if the designated
> initialiser syntax of C was taken  - and would that make it easier to
> retrofit into C?
>
>   void display(Screen& target, struct { int xres, int yres/*, etc..*/ });
> //<- compiler generated anonymous struct type
>
>   display(screen, { .yres=480, .xres=640});
>

Yes, I think reusing the C syntax makes the most sense here.

That also implies adding support for C tagged structure initialization to
C++, which implies defining how it works with constructors. At first pass,
I'd say only enable the syntax for POD structs. This would need to be
studied very carefully. I wouldn't be surprised if this was already brought
up in the past, studied, and rejected for some reason. Does anyone have
insight on that? Google doesn't appear to be helpful.


>
> [2] Would it also be a good way of doing multiple return values. Might
> actually be more pleasant than tuples in other languages.
>
>    auto do_something()-> struct { int x; int y  }
>

I did not think of that, but this is not a bad idea. The multiple return
values have names which makes the code much more understandable than using
tuples as you pointed out.


>
> [3] could it work with auto...
>
>    auto do_something() {
>        return {.x=..., .y=....}
>    }
>


Sure, as long as the parser can differentiate between an ordinary "tagged
initialization" expression and this expression which is an "anonymous type
declaration and tagged initialization" expression all in one.

It looks like this idea is really multiple proposals in one:

1. Add support for tagged struct initialization syntax for POD structs to
C++
2. Add support for anonymous structs
3. Add syntactic sugar (may not even be necessary) for function
declarations and invocations to use anonymous structs to support named
function arguments.
4. Implicit struct for call stack reflection? (May be an entirely different
idea to be discussed separately).


Can anyone suggest why this might be a terrible idea to pursue?

--

---
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_372_27833215.1402946332233
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Sunday, June 15, 2014 5:06:23 PM UTC-4, walter1=
234 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><di=
v>I agree anonymous structs would be a great feature.</div><div><br></div>[=
1] Would there be less risk of ambiguous parses if the designated initialis=
er syntax of C was taken &nbsp;- and would that make it easier to retrofit =
into C?&nbsp;<div><br></div><div><div>&nbsp; void display(Screen&amp; targe=
t, struct { int xres, int yres/*, etc..*/ }); //&lt;- compiler generated an=
onymous struct type</div><div><br></div><div>&nbsp; display(screen, { .yres=
=3D480, .xres=3D640});</div></div></div></blockquote><div><br>Yes, I think =
reusing the C syntax makes the most sense here. <br><br>That also implies a=
dding support for C tagged structure initialization to C++, which implies d=
efining how it works with constructors. At first pass, I'd say only enable =
the syntax for POD structs. This would need to be studied very carefully. I=
 wouldn't be surprised if this was already brought up in the past, studied,=
 and rejected for some reason. Does anyone have insight on that? Google doe=
sn't appear to be helpful.<br>&nbsp;<br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"><div dir=3D"ltr"><div><div><br></div><div>[2] Would it also=
 be a good way of doing multiple return values. Might actually be more plea=
sant than tuples in other languages.</div><div><br></div><div>&nbsp; &nbsp;=
auto do_something()-&gt; struct { int x; int y &nbsp;}</div></div></div></b=
lockquote><div><br>I did not think of that, but this is not a bad idea. The=
 multiple return values have names which makes the code much more understan=
dable than using tuples as you pointed out.<br>&nbsp;</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br></div><div>[3] could=
 it work with auto...</div><div><br></div><div>&nbsp; &nbsp;auto do_somethi=
ng() {</div><div>&nbsp; &nbsp; &nbsp; &nbsp;return {.x=3D..., .y=3D....}</d=
iv><div>&nbsp; &nbsp;}</div></div></blockquote><div><br><br>Sure, as long a=
s the parser can differentiate between an ordinary "tagged initialization" =
expression and this expression which is an "anonymous type declaration and =
tagged initialization" expression all in one.<br><br>It looks like this ide=
a is really multiple proposals in one:<br><br>1. Add support for tagged str=
uct initialization syntax for POD structs to C++<br>2. Add support for anon=
ymous structs<br>3. Add syntactic sugar (may not even be necessary) for fun=
ction declarations and invocations to use anonymous structs to support name=
d function arguments.<br>4. Implicit struct for call stack reflection? (May=
 be an entirely different idea to be discussed separately).<br><br><br>Can =
anyone suggest why this might be a terrible idea to pursue?<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_372_27833215.1402946332233--

.

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

Le lundi 16 juin 2014 21:18:52 UTC+2, Matthew Fioravante a =C3=A9crit :
>
> That also implies adding support for C tagged structure initialization to=
=20
> C++, which implies defining how it works with constructors. At first pass=
,=20
> I'd say only enable the syntax for POD structs. This would need to be=20
> studied very carefully. I wouldn't be surprised if this was already broug=
ht=20
> up in the past, studied, and rejected for some reason. Does anyone have=
=20
> insight on that? Google doesn't appear to be helpful.
>

A proposal has been written recently:
https://groups.google.com/a/isocpp.org/forum/#!msg/std-proposals/IgDFqKjKlR=
s/CGARpDJy9JsJ=20

I do not know what is the current status of that proposal though.

--=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_1258_31640951.1402955037469
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Le lundi 16 juin 2014 21:18:52 UTC+2, Matthew Fioravante a=
 =C3=A9crit&nbsp;:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr">That also implies adding support for C tagged structure initialization=
 to C++, which implies defining how it works with constructors. At first pa=
ss, I'd say only enable the syntax for POD structs. This would need to be s=
tudied very carefully. I wouldn't be surprised if this was already brought =
up in the past, studied, and rejected for some reason. Does anyone have ins=
ight on that? Google doesn't appear to be helpful.</div></blockquote><div><=
br>A proposal has been written recently:<br>https://groups.google.com/a/iso=
cpp.org/forum/#!msg/std-proposals/IgDFqKjKlRs/CGARpDJy9JsJ <br>I do not kno=
w what is the current status of that proposal though.<br></div><mytubeeleme=
nt data=3D"{&quot;bundle&quot;:{&quot;label_delimitor&quot;:&quot;:&quot;,&=
quot;percentage&quot;:&quot;%&quot;,&quot;smart_buffer&quot;:&quot;Smart Bu=
ffer&quot;,&quot;start_playing_when_buffered&quot;:&quot;Start playing when=
 buffered&quot;,&quot;sound&quot;:&quot;Sound&quot;,&quot;desktop_notificat=
ion&quot;:&quot;Desktop Notification&quot;,&quot;continuation_on_next_line&=
quot;:&quot;-&quot;,&quot;loop&quot;:&quot;Loop&quot;,&quot;only_notify&quo=
t;:&quot;Only Notify&quot;,&quot;estimated_time&quot;:&quot;Estimated Time&=
quot;,&quot;global_preferences&quot;:&quot;Global Preferences&quot;,&quot;n=
o_notification_supported_on_your_browser&quot;:&quot;No notification style =
supported on your browser version&quot;,&quot;video_buffered&quot;:&quot;Vi=
deo Buffered&quot;,&quot;buffered&quot;:&quot;Buffered&quot;,&quot;hyphen&q=
uot;:&quot;-&quot;,&quot;buffered_message&quot;:&quot;The video has been bu=
ffered as requested and is ready to play.&quot;,&quot;not_supported&quot;:&=
quot;Not Supported&quot;,&quot;on&quot;:&quot;On&quot;,&quot;off&quot;:&quo=
t;Off&quot;,&quot;click_to_enable_for_this_site&quot;:&quot;Click to enable=
 for this site&quot;,&quot;desktop_notification_denied&quot;:&quot;You have=
 denied permission for desktop notification for this site&quot;,&quot;notif=
ication_status_delimitor&quot;:&quot;;&quot;,&quot;error&quot;:&quot;Error&=
quot;,&quot;adblock_interferance_message&quot;:&quot;Adblock (or similar ex=
tension) is known to interfere with SmartVideo. Please add this url to adbl=
ock whitelist.&quot;,&quot;calculating&quot;:&quot;Calculating&quot;,&quot;=
waiting&quot;:&quot;Waiting&quot;,&quot;will_start_buffering_when_initializ=
ed&quot;:&quot;Will start buffering when initialized&quot;,&quot;will_start=
_playing_when_initialized&quot;:&quot;Will start playing when initialized&q=
uot;,&quot;completed&quot;:&quot;Completed&quot;,&quot;buffering_stalled&qu=
ot;:&quot;Buffering is stalled. Will stop.&quot;,&quot;stopped&quot;:&quot;=
Stopped&quot;,&quot;hr&quot;:&quot;Hr&quot;,&quot;min&quot;:&quot;Min&quot;=
,&quot;sec&quot;:&quot;Sec&quot;,&quot;any_moment&quot;:&quot;Any Moment&qu=
ot;,&quot;popup_donate_to&quot;:&quot;Donate to&quot;,&quot;extension_id&qu=
ot;:null},&quot;prefs&quot;:{&quot;desktopNotification&quot;:true,&quot;sou=
ndNotification&quot;:false,&quot;logLevel&quot;:0,&quot;enable&quot;:true,&=
quot;loop&quot;:false,&quot;hidePopup&quot;:true,&quot;autoPlay&quot;:false=
,&quot;autoBuffer&quot;:false,&quot;autoPlayOnBuffer&quot;:false,&quot;auto=
PlayOnBufferPercentage&quot;:42,&quot;autoPlayOnSmartBuffer&quot;:true,&quo=
t;quality&quot;:&quot;default&quot;,&quot;fshd&quot;:false,&quot;onlyNotifi=
cation&quot;:true,&quot;enableFullScreen&quot;:true,&quot;saveBandwidth&quo=
t;:false,&quot;hideAnnotations&quot;:true,&quot;turnOffPagedBuffering&quot;=
:true}}" event=3D"preferencesUpdated" id=3D"myTubeRelayElementToPage"></myt=
ubeelement><mytubeelement data=3D"{&quot;loadBundle&quot;:true}" event=3D"r=
elayPrefs" id=3D"myTubeRelayElementToTab"></mytubeelement></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_1258_31640951.1402955037469--

.

--Apple-Mail=_798AE96F-AA96-4531-BA4A-C563AEE3A8D2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-06-17, at 9:37 AM, David Krauss <potswa@gmail.com> wrote:

>=20
> On 2014-06-17, at 5:43 AM, corentin.schreiber@cea.fr wrote:
>=20
>> Le lundi 16 juin 2014 21:18:52 UTC+2, Matthew Fioravante a =E9crit :
>> That also implies adding support for C tagged structure initialization t=
o C++, which implies defining how it works with constructors. At first pass=
, I'd say only enable the syntax for POD structs. This would need to be stu=
died very carefully. I wouldn't be surprised if this was already brought up=
 in the past, studied, and rejected for some reason. Does anyone have insig=
ht on that? Google doesn't appear to be helpful.
>>=20
>> A proposal has been written recently:
>> https://groups.google.com/a/isocpp.org/forum/#!msg/std-proposals/IgDFqKj=
KlRs/CGARpDJy9JsJ=20
>> I do not know what is the current status of that proposal though.
>=20
> It would probably be better to make a clean start, based on review of dis=
cussions on this forum.
>=20
> Note, I was advocating the designated initializer solution earlier in thi=
s thread but nobody seemed to care at the time. Anyone who's interested mig=
ht check those posts.

Oh, it was the other thread. And my strongest point was that, even if named=
 parameters are implemented separately from pass-by-struct, folks will stil=
l combine designated initializers with pass-by-struct anyway. This results =
in two similar ways of doing the same thing, which should have similar if n=
ot same syntax.

This thread seems to be simply taking the alternative idea and running with=
 it. :)

One suggestion, but it's only that: the struct is the sole argument, then a=
llow designated initializer syntax directly in the argument list -- i.e., a=
llow brace elision.

struct rect {
    int top, left, bottom, right;

    rect( /* struct */ { int in_top, in_left, in_bottom, in_right; } )
        : top( in_top ), left( in_left ), bottom( in_bottom ), right( in_ri=
ght ) {}

    rect( /* struct */ { int in_top, in_left, in_height, in_width; } )
        : top( in_top ), left( in_left )
        , bottom( in_top + in_width ), right( in_left + in_width ) {}
};

rect a( .top =3D 4, .height =3D 43, .left =3D 10, .width =3D 100 );
rect b( .top =3D 4, .bottom =3D 47, .left =3D 10, .right =3D 110 );


--=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=_798AE96F-AA96-4531-BA4A-C563AEE3A8D2
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:37 AM, David Krauss &lt;<a href=3D"mailto:potswa@gm=
ail.com">potswa@gmail.com</a>&gt; wrote:</div><br class=3D"Apple-interchang=
e-newline"><blockquote type=3D"cite"><meta http-equiv=3D"Content-Type" cont=
ent=3D"text/html charset=3Dwindows-1252"><div style=3D"word-wrap: break-wor=
d; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><d=
iv><div>On 2014&ndash;06&ndash;17, at 5:43 AM, <a href=3D"mailto:corentin.s=
chreiber@cea.fr">corentin.schreiber@cea.fr</a> wrote:</div><br class=3D"App=
le-interchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr">Le lundi=
 16 juin 2014 21:18:52 UTC+2, Matthew Fioravante a =E9crit&nbsp;:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">That also implies addin=
g support for C tagged structure initialization to C++, which implies defin=
ing how it works with constructors. At first pass, I'd say only enable the =
syntax for POD structs. This would need to be studied very carefully. I wou=
ldn't be surprised if this was already brought up in the past, studied, and=
 rejected for some reason. Does anyone have insight on that? Google doesn't=
 appear to be helpful.</div></blockquote><div><br>A proposal has been writt=
en recently:<br><a href=3D"https://groups.google.com/a/isocpp.org/forum/#!m=
sg/std-proposals/IgDFqKjKlRs/CGARpDJy9JsJ">https://groups.google.com/a/isoc=
pp.org/forum/#!msg/std-proposals/IgDFqKjKlRs/CGARpDJy9JsJ</a> <br>I do not =
know what is the current status of that proposal though.<br></div><mytubeel=
ement data=3D"{&quot;bundle&quot;:{&quot;label_delimitor&quot;:&quot;:&quot=
;,&quot;percentage&quot;:&quot;%&quot;,&quot;smart_buffer&quot;:&quot;Smart=
 Buffer&quot;,&quot;start_playing_when_buffered&quot;:&quot;Start playing w=
hen buffered&quot;,&quot;sound&quot;:&quot;Sound&quot;,&quot;desktop_notifi=
cation&quot;:&quot;Desktop Notification&quot;,&quot;continuation_on_next_li=
ne&quot;:&quot;-&quot;,&quot;loop&quot;:&quot;Loop&quot;,&quot;only_notify&=
quot;:&quot;Only Notify&quot;,&quot;estimated_time&quot;:&quot;Estimated Ti=
me&quot;,&quot;global_preferences&quot;:&quot;Global Preferences&quot;,&quo=
t;no_notification_supported_on_your_browser&quot;:&quot;No notification sty=
le supported on your browser version&quot;,&quot;video_buffered&quot;:&quot=
;Video Buffered&quot;,&quot;buffered&quot;:&quot;Buffered&quot;,&quot;hyphe=
n&quot;:&quot;-&quot;,&quot;buffered_message&quot;:&quot;The video has been=
 buffered as requested and is ready to play.&quot;,&quot;not_supported&quot=
;:&quot;Not Supported&quot;,&quot;on&quot;:&quot;On&quot;,&quot;off&quot;:&=
quot;Off&quot;,&quot;click_to_enable_for_this_site&quot;:&quot;Click to ena=
ble for this site&quot;,&quot;desktop_notification_denied&quot;:&quot;You h=
ave denied permission for desktop notification for this site&quot;,&quot;no=
tification_status_delimitor&quot;:&quot;;&quot;,&quot;error&quot;:&quot;Err=
or&quot;,&quot;adblock_interferance_message&quot;:&quot;Adblock (or similar=
 extension) is known to interfere with SmartVideo. Please add this url to a=
dblock whitelist.&quot;,&quot;calculating&quot;:&quot;Calculating&quot;,&qu=
ot;waiting&quot;:&quot;Waiting&quot;,&quot;will_start_buffering_when_initia=
lized&quot;:&quot;Will start buffering when initialized&quot;,&quot;will_st=
art_playing_when_initialized&quot;:&quot;Will start playing when initialize=
d&quot;,&quot;completed&quot;:&quot;Completed&quot;,&quot;buffering_stalled=
&quot;:&quot;Buffering is stalled. Will stop.&quot;,&quot;stopped&quot;:&qu=
ot;Stopped&quot;,&quot;hr&quot;:&quot;Hr&quot;,&quot;min&quot;:&quot;Min&qu=
ot;,&quot;sec&quot;:&quot;Sec&quot;,&quot;any_moment&quot;:&quot;Any Moment=
&quot;,&quot;popup_donate_to&quot;:&quot;Donate to&quot;,&quot;extension_id=
&quot;:null},&quot;prefs&quot;:{&quot;desktopNotification&quot;:true,&quot;=
soundNotification&quot;:false,&quot;logLevel&quot;:0,&quot;enable&quot;:tru=
e,&quot;loop&quot;:false,&quot;hidePopup&quot;:true,&quot;autoPlay&quot;:fa=
lse,&quot;autoBuffer&quot;:false,&quot;autoPlayOnBuffer&quot;:false,&quot;a=
utoPlayOnBufferPercentage&quot;:42,&quot;autoPlayOnSmartBuffer&quot;:true,&=
quot;quality&quot;:&quot;default&quot;,&quot;fshd&quot;:false,&quot;onlyNot=
ification&quot;:true,&quot;enableFullScreen&quot;:true,&quot;saveBandwidth&=
quot;:false,&quot;hideAnnotations&quot;:true,&quot;turnOffPagedBuffering&qu=
ot;:true}}" event=3D"preferencesUpdated" id=3D"myTubeRelayElementToPage"></=
mytubeelement><mytubeelement data=3D"{&quot;loadBundle&quot;:true}" event=
=3D"relayPrefs" id=3D"myTubeRelayElementToTab"></mytubeelement></div></bloc=
kquote><br></div><div>It would probably be better to make a clean start, ba=
sed on review of discussions on this forum.</div><br><div>Note, I was advoc=
ating the designated initializer solution earlier in this thread but nobody=
 seemed to care at the time. Anyone who&rsquo;s interested might check thos=
e posts.</div></div></blockquote><div><br></div><div>Oh, it was the other t=
hread. And my strongest point was that, even if named parameters are implem=
ented separately from pass-by-struct, folks will still combine designated i=
nitializers with pass-by-struct anyway. This results in two similar ways of=
 doing the same thing, which should have similar if not same syntax.</div><=
div><br></div><div>This thread seems to be simply taking the alternative id=
ea and running with it. :)</div><div><br></div><div>One suggestion, but it&=
rsquo;s only that: the struct is the sole argument, then allow designated i=
nitializer syntax directly in the argument list &mdash; i.e., allow brace e=
lision.</div><div><br></div><div><font face=3D"Courier">struct rect {</font=
></div><div><font face=3D"Courier">&nbsp; &nbsp; int top, left, bottom, rig=
ht;</font></div><div><font face=3D"Courier"><br></font></div><div><font fac=
e=3D"Courier">&nbsp; &nbsp; rect( /* struct */ { int in_top, in_left, in_bo=
ttom, in_right; } )</font></div><div><font face=3D"Courier">&nbsp; &nbsp; &=
nbsp; &nbsp; : top( in_top ), left( in_left ), bottom( in_bottom ), right( =
in_right ) {}</font></div><div><font face=3D"Courier"><br></font></div><div=
><font face=3D"Courier">&nbsp; &nbsp; rect( /* struct */ { int in_top, in_l=
eft, in_height, in_width; } )</font></div><div><font face=3D"Courier">&nbsp=
; &nbsp; &nbsp; &nbsp; : top( in_top ), left( in_left )</font></div><div><f=
ont face=3D"Courier">&nbsp; &nbsp; &nbsp; &nbsp; , bottom( in_top + in_widt=
h ), right( in_left + in_width ) {}</font></div><div><font face=3D"Courier"=
>};</font></div><div><font face=3D"Courier"><br></font></div><div><font fac=
e=3D"Courier">rect a( .top =3D 4, .height =3D 43, .left =3D 10, .width =3D =
100 );</font></div><div><div><font face=3D"Courier">rect b( .top =3D 4, .bo=
ttom =3D 47, .left =3D 10, .right =3D 110 );</font></div><div><br></div><di=
v><br></div></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=_798AE96F-AA96-4531-BA4A-C563AEE3A8D2--

.

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



On Monday, June 16, 2014 9:52:38 PM UTC-4, David Krauss wrote:
>
>
> On 2014=E2=80=9306=E2=80=9317, at 9:37 AM, David Krauss <pot...@gmail.com=
 <javascript:>>=20
> wrote:
>
>
> On 2014=E2=80=9306=E2=80=9317, at 5:43 AM, corentin....@cea.fr <javascrip=
t:> wrote:
>
> Le lundi 16 juin 2014 21:18:52 UTC+2, Matthew Fioravante a =C3=A9crit :
>>
>> That also implies adding support for C tagged structure initialization t=
o=20
>> C++, which implies defining how it works with constructors. At first pas=
s,=20
>> I'd say only enable the syntax for POD structs. This would need to be=20
>> studied very carefully. I wouldn't be surprised if this was already brou=
ght=20
>> up in the past, studied, and rejected for some reason. Does anyone have=
=20
>> insight on that? Google doesn't appear to be helpful.
>>
>
> A proposal has been written recently:
>
> https://groups.google.com/a/isocpp.org/forum/#!msg/std-proposals/IgDFqKjK=
lRs/CGARpDJy9JsJ=20
> I do not know what is the current status of that proposal though.
>
>
> It would probably be better to make a clean start, based on review of=20
> discussions on this forum.
>
> Note, I was advocating the designated initializer solution earlier in thi=
s=20
> thread but nobody seemed to care at the time. Anyone who=E2=80=99s intere=
sted might=20
> check those posts.
>
>
> Oh, it was the other thread. And my strongest point was that, even if=20
> named parameters are implemented separately from pass-by-struct, folks wi=
ll=20
> still combine designated initializers with pass-by-struct anyway. This=20
> results in two similar ways of doing the same thing, which should have=20
> similar if not same syntax.
>

I completely agree with you that we must reuse designated initializer=20
syntax. Having 2 different syntax just complicates the language. Its=20
completely necessary. There's no bike shed to be painted here!
=20

> =20
>

> This thread seems to be simply taking the alternative idea and running=20
> with it. :)
>
> One suggestion, but it=E2=80=99s only that: the struct is the sole argume=
nt, then=20
> allow designated initializer syntax directly in the argument list =E2=80=
=94 i.e.,=20
> allow brace elision.
>
> struct rect {
>     int top, left, bottom, right;
>
>     rect( /* struct */ { int in_top, in_left, in_bottom, in_right; } )
>         : top( in_top ), left( in_left ), bottom( in_bottom ), right(=20
> in_right ) {}
>
>     rect( /* struct */ { int in_top, in_left, in_height, in_width; } )
>         : top( in_top ), left( in_left )
>         , bottom( in_top + in_width ), right( in_left + in_width ) {}
> };
>
> rect a( .top =3D 4, .height =3D 43, .left =3D 10, .width =3D 100 );
> rect b( .top =3D 4, .bottom =3D 47, .left =3D 10, .right =3D 110 );
>
>
The original style:

int foo(int a, int b, string c);
foo(.a =3D 0, .b =3D 1, .c =3D "Hello");=20

Pros:
- Very simple
- No ABI changes
- All legacy code immediately becomes named function enabled
Cons:
- Cannot use named syntax when calling via a function pointer, since the=20
type has no concept of parameter names.
- Requires some language changes to enable the callsite syntax
- Argument names while not part of the ABI, are now part of the API. You=20
cannot change the names or you will break callers.=20
- All legacy code immediately becomes named function enabled.

The struct approach
int foo(int a, {int b; int c;}, }

Pros:
-Separates positional and named arguments. Is this desirable??
-No ABI changes again, just reuses the type system with anonymous structs
-Function pointers can also be name initialized when called, since their=20
type encodes the type of the struct, and the struct can be initialized=20
using tagged init syntax. This sounds like a big win.
-No special rules, all syntax inherited from struct
Cons;
-Functions with same arguments still have different types.
-Requires anonymous structs proposal
-If you have 2 overloads, with same positional arguments and different=20
structs, how do you choose which one to pick from initializer syntax?=20

void foo(int a, {int b; int c;});
void foo(int a, {string b=3D"", string c=3D""});

foo(1, {.c =3D "hello" });

I suppose the naming rule here could try to initialize each instance of foo=
=20
using the brace expression in order of appearance in an SFINAE like manner.


> I=E2=80=99d also help draft such a proposal if someone wants a collaborat=
or.=20
Right now I=E2=80=99m hoping to attend the November meeting > in Champaign,=
=20
although it=E2=80=99s not a guarantee and I might have a full plate with ot=
her=20
proposals. However, at this point a
> paper exploring the design space might be more appropriate than an=20
attempt at fully-baked wording, which reduces the=20
> burden of advocacy. There are a number of issues and corner cases to=20
check, and the committee needs to approve the=20
> =E2=80=9Cwhat=E2=80=9D before the =E2=80=9Chow.=E2=80=9D

Does it make sense to cram all of these sort of unrelated things into one=
=20
big proposal? Or do it incrementally with multiple proposals with the big=
=20
picture in mind?

I could start writing one or help with writing one and fleshing out the=20
details. It would be great to have someone actually present it at the=20
meetings, since I don't actually have the ability to attend myself.

--=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_2016_7386306.1402973170506
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Monday, June 16, 2014 9:52:38 PM UTC-4, David K=
rauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word=
-wrap:break-word"><br><div><div>On 2014=E2=80=9306=E2=80=9317, at 9:37 AM, =
David Krauss &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-m=
ailto=3D"ur3eSQj9Q7cJ" onmousedown=3D"this.href=3D'javascript:';return true=
;" onclick=3D"this.href=3D'javascript:';return true;">pot...@gmail.com</a>&=
gt; wrote:</div><br><blockquote type=3D"cite"><div style=3D"word-wrap:break=
-word"><br><div><div>On 2014=E2=80=9306=E2=80=9317, at 5:43 AM, <a href=3D"=
javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"ur3eSQj9Q7cJ" onmou=
sedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'j=
avascript:';return true;">corentin....@cea.fr</a> wrote:</div><br><blockquo=
te type=3D"cite"><div dir=3D"ltr">Le lundi 16 juin 2014 21:18:52 UTC+2, Mat=
thew Fioravante a =C3=A9crit&nbsp;:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr">That also implies adding support for C tagged structure i=
nitialization to C++, which implies defining how it works with constructors=
.. At first pass, I'd say only enable the syntax for POD structs. This would=
 need to be studied very carefully. I wouldn't be surprised if this was alr=
eady brought up in the past, studied, and rejected for some reason. Does an=
yone have insight on that? Google doesn't appear to be helpful.</div></bloc=
kquote><div><br>A proposal has been written recently:<br><a href=3D"https:/=
/groups.google.com/a/isocpp.org/forum/#!msg/std-proposals/IgDFqKjKlRs/CGARp=
DJy9JsJ" target=3D"_blank" onmousedown=3D"this.href=3D'https://groups.googl=
e.com/a/isocpp.org/forum/#!msg/std-proposals/IgDFqKjKlRs/CGARpDJy9JsJ';retu=
rn true;" onclick=3D"this.href=3D'https://groups.google.com/a/isocpp.org/fo=
rum/#!msg/std-proposals/IgDFqKjKlRs/CGARpDJy9JsJ';return true;">https://gro=
ups.google.com/a/<wbr>isocpp.org/forum/#!msg/std-<wbr>proposals/IgDFqKjKlRs=
/<wbr>CGARpDJy9JsJ</a> <br>I do not know what is the current status of that=
 proposal though.<br></div></div></blockquote><br></div><div>It would proba=
bly be better to make a clean start, based on review of discussions on this=
 forum.</div><br><div>Note, I was advocating the designated initializer sol=
ution earlier in this thread but nobody seemed to care at the time. Anyone =
who=E2=80=99s interested might check those posts.</div></div></blockquote><=
div><br></div><div>Oh, it was the other thread. And my strongest point was =
that, even if named parameters are implemented separately from pass-by-stru=
ct, folks will still combine designated initializers with pass-by-struct an=
yway. This results in two similar ways of doing the same thing, which shoul=
d have similar if not same syntax.</div></div></div></blockquote><div><br><=
/div><div><font size=3D"2">I completely agree with you that we must reuse d=
esignated initializer syntax. Having 2 different syntax just complicates th=
e language. Its completely&nbsp;</font>necessary<font size=3D"2">. There's =
no bike shed to be painted here!</font></div><div>&nbsp;</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
 #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:break-word"><div><d=
iv><span style=3D"font-size: 13px;">&nbsp;</span></div></div></div></blockq=
uote><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:b=
reak-word"><div><div><br></div><div>This thread seems to be simply taking t=
he alternative idea and running with it. :)</div><div><br></div><div>One su=
ggestion, but it=E2=80=99s only that: the struct is the sole argument, then=
 allow designated initializer syntax directly in the argument list =E2=80=
=94 i.e., allow brace elision.</div><div><br></div><div><font face=3D"Couri=
er">struct rect {</font></div><div><font face=3D"Courier">&nbsp; &nbsp; int=
 top, left, bottom, right;</font></div><div><font face=3D"Courier"><br></fo=
nt></div><div><font face=3D"Courier">&nbsp; &nbsp; rect( /* struct */ { int=
 in_top, in_left, in_bottom, in_right; } )</font></div><div><font face=3D"C=
ourier">&nbsp; &nbsp; &nbsp; &nbsp; : top( in_top ), left( in_left ), botto=
m( in_bottom ), right( in_right ) {}</font></div><div><font face=3D"Courier=
"><br></font></div><div><font face=3D"Courier">&nbsp; &nbsp; rect( /* struc=
t */ { int in_top, in_left, in_height, in_width; } )</font></div><div><font=
 face=3D"Courier">&nbsp; &nbsp; &nbsp; &nbsp; : top( in_top ), left( in_lef=
t )</font></div><div><font face=3D"Courier">&nbsp; &nbsp; &nbsp; &nbsp; , b=
ottom( in_top + in_width ), right( in_left + in_width ) {}</font></div><div=
><font face=3D"Courier">};</font></div><div><font face=3D"Courier"><br></fo=
nt></div><div><font face=3D"Courier">rect a( .top =3D 4, .height =3D 43, .l=
eft =3D 10, .width =3D 100 );</font></div><div><div><font face=3D"Courier">=
rect b( .top =3D 4, .bottom =3D 47, .left =3D 10, .right =3D 110 );</font><=
/div><div><br></div></div></div></div></blockquote><div><br></div><div>The =
original style:</div><div><br></div><div>int foo(int a, int b, string c);</=
div><div>foo(.a =3D 0, .b =3D 1, .c =3D "Hello");&nbsp;</div><div><br></div=
><div>Pros:</div><div>- Very simple</div><div>- No ABI changes</div><div>- =
All legacy code immediately becomes named function enabled</div><div>Cons:<=
/div><div>- Cannot use named syntax when calling via a function pointer, si=
nce the type has no concept of parameter names.</div><div>- Requires some l=
anguage changes to enable the callsite syntax</div><div>- Argument names wh=
ile not part of the ABI, are now part of the API. You cannot change the nam=
es or you will break callers.&nbsp;</div><div>- All legacy code immediately=
 becomes named function enabled.</div><div><br></div><div>The struct approa=
ch</div><div>int foo(int a, {int b; int c;}, }</div><div><br></div><div>Pro=
s:</div><div>-Separates positional and named arguments. Is this desirable??=
</div><div>-No ABI changes again, just reuses the type system with anonymou=
s structs</div><div>-Function pointers can also be name initialized when ca=
lled, since their type encodes the type of the struct, and the struct can b=
e initialized using tagged init syntax. This sounds like a big win.</div><d=
iv>-No special rules, all syntax inherited from struct</div><div>Cons;</div=
><div>-Functions with same arguments still have different types.</div><div>=
-Requires anonymous structs proposal</div><div>-If you have 2 overloads, wi=
th same positional arguments and different structs, how do you choose which=
 one to pick from initializer syntax?&nbsp;</div><div><br></div><div>void f=
oo(int a, {int b; int c;});</div><div>void foo(int a, {string b=3D"", strin=
g c=3D""});</div><div><br></div><div>foo(1, {.c =3D "hello" });</div><div><=
br></div><div>I suppose the naming rule here could try to initialize each i=
nstance of foo using the brace expression in order of appearance in an SFIN=
AE like manner.</div><div><br></div><div><br></div><div>&gt; I=E2=80=99d al=
so help draft such a proposal if someone wants a collaborator. Right now I=
=E2=80=99m hoping to attend the November meeting &gt; in Champaign, althoug=
h it=E2=80=99s not a guarantee and I might have a full plate with other pro=
posals. However, at this point a</div><div>&gt; paper exploring the design =
space might be more appropriate than an attempt at fully-baked wording, whi=
ch reduces the&nbsp;</div><div>&gt; burden of advocacy. There are a number =
of issues and corner cases to check, and the committee needs to approve the=
&nbsp;</div><div>&gt; =E2=80=9Cwhat=E2=80=9D before the =E2=80=9Chow.=E2=80=
=9D<br></div><div><br></div><div>Does it make sense to cram all of these so=
rt of unrelated things into one big proposal? Or do it incrementally with m=
ultiple proposals with the big picture in mind?<br></div><div><br></div><di=
v>I could start writing one or help with writing one and fleshing out the d=
etails. It would be great to have someone actually present it at the meetin=
gs, since I don't actually have the ability to attend myself.</div><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&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_2016_7386306.1402973170506--

.

--Apple-Mail=_6F5ABA76-EA52-426A-A413-C887A36AEF8B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-06-17, at 10:46 AM, Matthew Fioravante <fmatthew5876@gmail.com> wro=
te:
=20
> The original style:
>=20
> int foo(int a, int b, string c);
> foo(.a =3D 0, .b =3D 1, .c =3D "Hello");=20
>=20
> Pros:
> - Very simple
> - No ABI changes
> - All legacy code immediately becomes named function enabled
> Cons:

The big con is that without ABI support, there's no overloading. My example=
 wouldn't work because both rect::rect overloads would mangle to the same n=
ame.

> - Cannot use named syntax when calling via a function pointer, since the =
type has no concept of parameter names.
> - Requires some language changes to enable the callsite syntax
> - Argument names while not part of the ABI, are now part of the API. You =
cannot change the names or you will break callers.=20

This is sort-of inherent to the feature, but it suggests that having foreig=
n (member declaration) syntax for named parameters is actually a good thing=
..

> - All legacy code immediately becomes named function enabled.
>=20
> The struct approach
> int foo(int a, {int b; int c;}, }
>=20
> Pros:
> -Separates positional and named arguments. Is this desirable??

It's desirable that we give some specific meaning to each way an interface =
may be specified.

My suggestion of brace elision is designed to keep positional and named arg=
uments separate only as long as the interface allows them to be combined.

Partitioning the parameter list into groups sounds like a good idea to me. =
C99 specifies that undesignated initializers after a designated one initial=
ize successive members. Adding a separator between the named parameters and=
 succeeding unnamed ones prevents initializers from accidentally overflowin=
g.

struct point {
    int top, left;
};

struct rect {
    point top_left, bottom_right;
    float angle;

    rect( /* struct */ { int top, left, bottom, right; }, float in_angle =
=3D 0 )
        : top( top ), left( left ), bottom( bottom ), right( right ), angle=
( in_angle ) {}

    rect( /* struct */ { int top, left, height, width; }, float in_angle =
=3D 0 )
        : top( in_top ), left( in_left )
        , bottom( in_top + in_width ), right( in_left + in_width )
        , angle( in_angle ) {}

    rect( /* struct */ { point top_left, point bottom_right; }, float in_an=
gle =3D 0 )
        : top_left( top_left ), bottom_right( bottom_right ), angle( in_ang=
le ) {}
};

rect a( .top =3D 4, .height =3D 43, .left =3D 10, .width =3D 100 ); // OK
rect b( .top_left =3D { 4, 43 }, .bottom_right =3D { 10, 100 } ); // OK
rect c( .top_left =3D 4, 43, .bottom_right =3D 10, 100 ); // OK: (additiona=
l) brace elision
rect d( .top =3D 4, 43, .bottom =3D 10, 100 ); // OK: initialize successive=
 members.
rect e( .top =3D 4, 43, 10, 100 ); // Error: ambiguous.
rect f( 4, 43, .bottom =3D 10, 100 ); // OK, if poor style, the user is ask=
ing for it.
rect g( .top =3D 4, .bottom =3D 47, .left =3D 10, .right =3D 110, 35_degree=
s ); // Error: mixed named and unnamed
rect h( { .top =3D 4, .bottom =3D 47, .left =3D 10, .right =3D 110 }, 35_de=
grees ); // OK


> -No ABI changes again, just reuses the type system with anonymous structs
> -Function pointers can also be name initialized when called, since their =
type encodes the type of the struct, and the struct can be initialized usin=
g tagged init syntax. This sounds like a big win.
> -No special rules, all syntax inherited from struct

I wonder, is dropping the struct keyword really a good idea? The member dec=
laration syntax differs from parameter declarations and it serves as a usef=
ul reminder to the author, even if it hinders grokking the interface.

> Cons;
> -Functions with same arguments still have different types.

Support for taking a function pointer might be an interface feature, requir=
ing the parameter type to get a name.

Given that, a generic facility can create a wrapper that takes arguments ac=
cording to the function pointer type, and passes them through the named par=
ameter struct type.

> -Requires anonymous structs proposal

This is just adopting another feature from C. Extra motivation for cross-co=
mpatibility is a good thing.

> -If you have 2 overloads, with same positional arguments and different st=
ructs, how do you choose which one to pick from initializer syntax?=20
>=20
> void foo(int a, {int b; int c;});
> void foo(int a, {string b=3D"", string c=3D""});
>=20
> foo(1, {.c =3D "hello" });
>=20
> I suppose the naming rule here could try to initialize each instance of f=
oo using the brace expression in order of appearance in an SFINAE like mann=
er.

I don't see an issue here. Types and names represent independent constraint=
s.

I hadn't thought about SFINAE or templates, but now that you mention it, na=
med parameters as members cannot be a template parameter deduction context.=
 Might need addressing.

> > I'd also help draft such a proposal if someone wants a collaborator. Ri=
ght now I'm hoping to attend the November meeting > in Champaign, although =
it's not a guarantee and I might have a full plate with other proposals. Ho=
wever, at this point a
> > paper exploring the design space might be more appropriate than an atte=
mpt at fully-baked wording, which reduces the=20
> > burden of advocacy. There are a number of issues and corner cases to ch=
eck, and the committee needs to approve the=20
> > "what" before the "how."
>=20
> Does it make sense to cram all of these sort of unrelated things into one=
 big proposal? Or do it incrementally with multiple proposals with the big =
picture in mind?

I don't have any real experience yet, but my preference would be to port de=
signated initializers in one paper, anonymous structs in a second, and spec=
ify the application to named parameters in a third paper. Ideally, present =
them simultaneously. However, it's a lot of ground to cover. Designated ini=
tializers will have a lot of interactions with existing initialization feat=
ures like brace-or-equal-initializers. I think that's one session, and then=
 anonymous structs can be done in the same session as named parameters, sin=
ce they're relatively minor alone. (I don't even recall whether they have a=
ny applications outside unions.)

> I could start writing one or help with writing one and fleshing out the d=
etails. It would be great to have someone actually present it at the meetin=
gs, since I don't actually have the ability to attend myself.

My plans are to write up inline variables, present the preprocessor revisio=
n N3881/N3882 which wasn't presented at Issaquah, and hopefully write-up an=
d present some ideas about scope guards and multithreaded exception handlin=
g. So, that's already a lot.

I think full standardese would be overkill in an initial presentation. The =
papers would be complete without it. There's plenty of time before C++17 an=
d we just need to get a foot in the door.

The first thing is to port designated initializers, and the first step ther=
e is to try and enumerate all the corner cases. It's somewhat tangential, b=
ut still worthwhile. The C porting work should decide such things as how to=
 provide default arguments to named parameters/members. Ideally the named p=
arameters feature will just magically work when parameters are allowed to c=
ontain class-specifiers, so that paper would be the smallest.

--=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=_6F5ABA76-EA52-426A-A413-C887A36AEF8B
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 10:46 AM, Matthew Fioravante &lt;<a href=3D"mailto:fm=
atthew5876@gmail.com">fmatthew5876@gmail.com</a>&gt; wrote:</div><div><span=
 style=3D"font-size: 13px;">&nbsp;</span></div><blockquote type=3D"cite"><d=
iv style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; fo=
nt-variant: normal; font-weight: normal; letter-spacing: normal; line-heigh=
t: normal; orphans: auto; text-align: start; text-indent: 0px; text-transfo=
rm: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-tex=
t-stroke-width: 0px;"><div dir=3D"ltr"><div>The original style:</div><div><=
br></div><div>int foo(int a, int b, string c);</div><div>foo(.a =3D 0, .b =
=3D 1, .c =3D "Hello");&nbsp;</div><div><br></div><div>Pros:</div><div>- Ve=
ry simple</div><div>- No ABI changes</div><div>- All legacy code immediatel=
y becomes named function enabled</div><div>Cons:</div></div></div></blockqu=
ote><div><br></div><div>The big con is that without ABI support, there&rsqu=
o;s no overloading. My example wouldn&rsquo;t work because both <font face=
=3D"Courier">rect::rect</font> overloads would mangle to the same name.</di=
v><br><blockquote type=3D"cite"><div style=3D"font-family: Helvetica; font-=
size: 12px; font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: auto; text-align: sta=
rt; text-indent: 0px; text-transform: none; white-space: normal; widows: au=
to; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div dir=3D"ltr"><d=
iv>- Cannot use named syntax when calling via a function pointer, since the=
 type has no concept of parameter names.</div><div>- Requires some language=
 changes to enable the callsite syntax</div><div>- Argument names while not=
 part of the ABI, are now part of the API. You cannot change the names or y=
ou will break callers.&nbsp;</div></div></div></blockquote><div><br></div><=
div>This is sort-of inherent to the feature, but it suggests that having fo=
reign (member declaration) syntax for named parameters is actually a good t=
hing.</div><br><blockquote type=3D"cite"><div style=3D"font-family: Helveti=
ca; font-size: 12px; font-style: normal; font-variant: normal; font-weight:=
 normal; letter-spacing: normal; line-height: normal; orphans: auto; text-a=
lign: start; text-indent: 0px; text-transform: none; white-space: normal; w=
idows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div dir=
=3D"ltr"><div>- All legacy code immediately becomes named function enabled.=
</div></div></div></blockquote><blockquote type=3D"cite"><div style=3D"font=
-family: Helvetica; font-size: 12px; font-style: normal; font-variant: norm=
al; font-weight: normal; letter-spacing: normal; line-height: normal; orpha=
ns: auto; text-align: start; text-indent: 0px; text-transform: none; white-=
space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: =
0px;"><div dir=3D"ltr"><div><br></div><div>The struct approach</div><div>in=
t foo(int a, {int b; int c;}, }</div><div><br></div><div>Pros:</div><div>-S=
eparates positional and named arguments. Is this desirable??</div></div></d=
iv></blockquote><div><br></div><div>It&rsquo;s desirable that we give some =
specific meaning to each way an interface may be specified.</div><div><br><=
/div><div>My suggestion of brace elision is designed to keep positional and=
 named arguments separate only as long as the interface allows them to be c=
ombined.</div><div><br></div><div>Partitioning the parameter list into grou=
ps sounds like a good idea to me. C99 specifies that undesignated initializ=
ers after a designated one initialize successive members. Adding a separato=
r between the named parameters and succeeding unnamed ones prevents initial=
izers from accidentally overflowing.</div><div><br></div><div><font face=3D=
"Courier">struct point {</font></div><div><font face=3D"Courier">&nbsp; &nb=
sp; int top, left;</font></div><div><font face=3D"Courier">};</font></div><=
div><font face=3D"Courier"><br></font></div><div><font face=3D"Courier">str=
uct rect {<br>&nbsp; &nbsp; point top_left, bottom_right;</font></div><div>=
<font face=3D"Courier">&nbsp; &nbsp; float angle;<br><br>&nbsp; &nbsp; rect=
( /* struct */ { int top, left, bottom, right; }, float in_angle =3D 0 )<br=
>&nbsp; &nbsp; &nbsp; &nbsp; : top( top ), left( left ), bottom( bottom ), =
right( right ), angle( in_angle ) {}<br><br></font></div><div><font face=3D=
"Courier">&nbsp; &nbsp; rect( /* struct */ { int top, left, height, width; =
}, float in_angle =3D 0 )<br>&nbsp; &nbsp; &nbsp; &nbsp; : top( in_top ), l=
eft( in_left )<br>&nbsp; &nbsp; &nbsp; &nbsp; , bottom( in_top + in_width )=
, right( in_left + in_width )</font></div><div><font face=3D"Courier">&nbsp=
; &nbsp; &nbsp; &nbsp; , angle( in_angle ) {}<br><br>&nbsp; &nbsp; rect( /*=
 struct */ { point top_left, point bottom_right; }, float in_angle =3D 0 )<=
br>&nbsp; &nbsp; &nbsp; &nbsp; : top_left( top_left ), bottom_right( bottom=
_right ),&nbsp;angle( in_angle&nbsp;) {}<br>};<br><br>rect a( .top =3D 4, .=
height =3D 43, .left =3D 10, .width =3D 100 ); // OK<br>rect b( .top_left =
=3D { 4, 43 }, .bottom_right =3D { 10, 100 } ); // OK<br>rect c( .top_left =
=3D 4, 43, .bottom_right =3D 10, 100 ); // OK: (additional) brace elision<b=
r></font><span style=3D"font-family: Courier;">rect d( .top =3D 4, 43, .bot=
tom =3D 10, 100 ); // OK: initialize successive members.</span><br style=3D=
"font-family: Courier;"><font face=3D"Courier">rect e( .top =3D 4, 43, 10, =
100 ); // Error: ambiguous.<br></font><span style=3D"font-family: Courier;"=
>rect f( 4, 43, .bottom =3D 10, 100 ); // OK, if poor style, the user is as=
king for it.</span><br style=3D"font-family: Courier;"><font face=3D"Courie=
r">rect g( .top =3D 4, .bottom =3D 47, .left =3D 10, .right =3D 110, 35_deg=
rees ); // Error: mixed named and unnamed<br>rect h( { .top =3D 4, .bottom =
=3D 47, .left =3D 10, .right =3D 110 }, 35_degrees ); // OK<br></font></div=
><div><br></div><br><blockquote type=3D"cite"><div style=3D"font-family: He=
lvetica; font-size: 12px; font-style: normal; font-variant: normal; font-we=
ight: normal; letter-spacing: normal; line-height: normal; orphans: auto; t=
ext-align: start; text-indent: 0px; text-transform: none; white-space: norm=
al; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div =
dir=3D"ltr"><div>-No ABI changes again, just reuses the type system with an=
onymous structs</div><div>-Function pointers can also be name initialized w=
hen called, since their type encodes the type of the struct, and the struct=
 can be initialized using tagged init syntax. This sounds like a big win.</=
div><div>-No special rules, all syntax inherited from struct</div></div></d=
iv></blockquote><div><br></div><div>I wonder, is dropping the <font face=3D=
"Courier">struct</font> keyword really a good idea? The member declaration =
syntax differs from parameter declarations and it serves as a useful remind=
er to the author, even if it hinders grokking the interface.</div><br><bloc=
kquote type=3D"cite"><div style=3D"font-family: Helvetica; font-size: 12px;=
 font-style: normal; font-variant: normal; font-weight: normal; letter-spac=
ing: normal; line-height: normal; orphans: auto; text-align: start; text-in=
dent: 0px; text-transform: none; white-space: normal; widows: auto; word-sp=
acing: 0px; -webkit-text-stroke-width: 0px;"><div dir=3D"ltr"><div>Cons;</d=
iv><div>-Functions with same arguments still have different types.</div></d=
iv></div></blockquote><div><br></div><div>Support for taking a function poi=
nter might be an interface feature, requiring the parameter type to get a n=
ame.</div><div><br></div><div>Given that, a generic facility can create a w=
rapper that takes arguments according to the function pointer type, and pas=
ses them through the named parameter struct type.</div><div><br></div><bloc=
kquote type=3D"cite"><div style=3D"font-family: Helvetica; font-size: 12px;=
 font-style: normal; font-variant: normal; font-weight: normal; letter-spac=
ing: normal; line-height: normal; orphans: auto; text-align: start; text-in=
dent: 0px; text-transform: none; white-space: normal; widows: auto; word-sp=
acing: 0px; -webkit-text-stroke-width: 0px;"><div dir=3D"ltr"><div>-Require=
s anonymous structs proposal</div></div></div></blockquote><div><br></div><=
div>This is just adopting another feature from C. Extra motivation for cros=
s-compatibility is a good thing.</div><br><blockquote type=3D"cite"><div st=
yle=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-va=
riant: normal; font-weight: normal; letter-spacing: normal; line-height: no=
rmal; orphans: auto; text-align: start; text-indent: 0px; text-transform: n=
one; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-str=
oke-width: 0px;"><div dir=3D"ltr"><div>-If you have 2 overloads, with same =
positional arguments and different structs, how do you choose which one to =
pick from initializer syntax?&nbsp;</div><div><br></div><div>void foo(int a=
, {int b; int c;});</div><div>void foo(int a, {string b=3D"", string c=3D""=
});</div><div><br></div><div>foo(1, {.c =3D "hello" });</div><div><br></div=
><div>I suppose the naming rule here could try to initialize each instance =
of foo using the brace expression in order of appearance in an SFINAE like =
manner.</div></div></div></blockquote><div><br></div><div>I don&rsquo;t see=
 an issue here. Types and names represent independent constraints.</div><di=
v><br></div><div>I hadn&rsquo;t thought about SFINAE or templates, but now =
that you mention it, named parameters as members cannot be a template param=
eter deduction context. Might need addressing.</div><br><blockquote type=3D=
"cite"><div style=3D"font-family: Helvetica; font-size: 12px; font-style: n=
ormal; font-variant: normal; font-weight: normal; letter-spacing: normal; l=
ine-height: normal; orphans: auto; text-align: start; text-indent: 0px; tex=
t-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -w=
ebkit-text-stroke-width: 0px;"><div dir=3D"ltr"><div>&gt; I&rsquo;d also he=
lp draft such a proposal if someone wants a collaborator. Right now I&rsquo=
;m hoping to attend the November meeting &gt; in Champaign, although it&rsq=
uo;s not a guarantee and I might have a full plate with other proposals. Ho=
wever, at this point a</div><div>&gt; paper exploring the design space migh=
t be more appropriate than an attempt at fully-baked wording, which reduces=
 the&nbsp;</div><div>&gt; burden of advocacy. There are a number of issues =
and corner cases to check, and the committee needs to approve the&nbsp;</di=
v><div>&gt; &ldquo;what&rdquo; before the &ldquo;how.&rdquo;<br></div><div>=
<br></div><div>Does it make sense to cram all of these sort of unrelated th=
ings into one big proposal? Or do it incrementally with multiple proposals =
with the big picture in mind?<br></div></div></div></blockquote><div><br></=
div><div>I don&rsquo;t have any real experience yet, but my preference woul=
d be to port designated initializers in one paper, anonymous structs in a s=
econd, and specify the application to named parameters in a third paper. Id=
eally, present them simultaneously. However, it&rsquo;s a lot of ground to =
cover. Designated initializers will have a lot of interactions with existin=
g initialization features like brace-or-equal-initializers. I think that&rs=
quo;s one session, and then anonymous structs can be done in the same sessi=
on as named parameters, since they&rsquo;re relatively minor alone. (I don&=
rsquo;t even recall whether they have any applications outside unions.)</di=
v><br><blockquote type=3D"cite"><div style=3D"font-family: Helvetica; font-=
size: 12px; font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: auto; text-align: sta=
rt; text-indent: 0px; text-transform: none; white-space: normal; widows: au=
to; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div dir=3D"ltr"><d=
iv>I could start writing one or help with writing one and fleshing out the =
details. It would be great to have someone actually present it at the meeti=
ngs, since I don't actually have the ability to attend myself.</div></div><=
/div></blockquote><div><br></div></div>My plans are to write up inline vari=
ables, present the preprocessor revision N3881/N3882 which wasn&rsquo;t pre=
sented at Issaquah, and hopefully write-up and present some ideas about sco=
pe guards and multithreaded exception handling. So, that&rsquo;s already a =
lot.<div><br></div><div>I think full standardese would be overkill in an in=
itial presentation. The papers would be complete without it. There&rsquo;s =
plenty of time before C++17 and we just need to get a foot in the door.</di=
v><div><br></div><div>The first thing is to port designated initializers, a=
nd the first step there is to try and enumerate all the corner cases. It&rs=
quo;s somewhat tangential, but still worthwhile. The C porting work should =
decide such things as how to provide default arguments to named parameters/=
members. Ideally the named parameters feature will just magically work when=
 parameters are allowed to contain class-specifiers, so that paper would be=
 the smallest.</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 />

--Apple-Mail=_6F5ABA76-EA52-426A-A413-C887A36AEF8B--

.

------=_Part_1872_16270915.1402980492880
Content-Type: text/plain; charset=UTF-8

I'm starting work on a paper for all of these features here:

https://github.com/fmatthew5876/stdcxx-struct

For now I'm just going to get all of the ideas into one paper with the
motivation, problems, details etc.. We can work out some of the details in
discussion and if the paper needs to be broken up into multiple papers that
can be done later.

I'll update the thread when I have something substantial to share and
discuss.

--

---
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_1872_16270915.1402980492880
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I'm starting work on a paper for all of these features her=
e:<div><br></div><div>https://github.com/fmatthew5876/stdcxx-struct<br></di=
v><div><br></div><div>For now I'm just going to get all of the ideas into o=
ne paper with the motivation, problems, details etc.. We can work out some =
of the details in discussion and if the paper needs to be broken up into mu=
ltiple papers that can be done later.</div><div><br></div><div>I'll update =
the thread when I have something substantial to share and discuss.</div></d=
iv>

<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_1872_16270915.1402980492880--

.

Em ter 17 jun 2014, =E0s 12:43:19, David Krauss escreveu:
> On 2014-06-17, at 10:46 AM, Matthew Fioravante <fmatthew5876@gmail.com>=
=20
wrote:
> > The original style:
> >=20
> > int foo(int a, int b, string c);
> > foo(.a =3D 0, .b =3D 1, .c =3D "Hello");
> >=20
> > Pros:
> > - Very simple
> > - No ABI changes
> > - All legacy code immediately becomes named function enabled
>=20
> > Cons:
> The big con is that without ABI support, there's no overloading. My examp=
le
> wouldn't work because both rect::rect overloads would mangle to the same
> name.

Use a tag struct as a differentiator:

 struct TopLeftBottomRight {};
 rect(int top, int left, int bottom, int right, TopLeftBottomRight =3D {})
=09
 struct TopLeftWidthHeight {};
 rect(int top, int left, int width, int height, TopLeftWidthHeight =3D {});

> > - Cannot use named syntax when calling via a function pointer, since th=
e
> > type has no concept of parameter names. - Requires some language change=
s
> > to enable the callsite syntax
> > - Argument names while not part of the ABI, are now part of the API. Yo=
u
> > cannot change the names or you will break callers.
> This is sort-of inherent to the feature, but it suggests that having fore=
ign
> (member declaration) syntax for named parameters is actually a good thing=
..

You can specify parameter names in the function pointer syntax...

--=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/.

.

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



On Tuesday, June 17, 2014 1:10:40 AM UTC-4, Thiago Macieira wrote:
>
> Em ter 17 jun 2014, =C3=A0s 12:43:19, David Krauss escreveu:=20
> > On 2014-06-17, at 10:46 AM, Matthew Fioravante <fmatth...@gmail.com=20
> <javascript:>>=20
> wrote:=20
> > > The original style:=20
> > >=20
> > > int foo(int a, int b, string c);=20
> > > foo(.a =3D 0, .b =3D 1, .c =3D "Hello");=20
> > >=20
> > > Pros:=20
> > > - Very simple=20
> > > - No ABI changes=20
> > > - All legacy code immediately becomes named function enabled=20
> >=20
> > > Cons:=20
> > The big con is that without ABI support, there's no overloading. My=20
> example=20
> > wouldn't work because both rect::rect overloads would mangle to the sam=
e=20
> > name.=20
>
> Use a tag struct as a differentiator:=20
>
>         struct TopLeftBottomRight {};=20
>         rect(int top, int left, int bottom, int right, TopLeftBottomRight=
=20
> =3D {})=20
>         =20
>         struct TopLeftWidthHeight {};=20
>         rect(int top, int left, int width, int height, TopLeftWidthHeight=
=20
> =3D {});=20
>
> That's one way to do it, if we cannot come up with a nice naming rule.

> > - Cannot use named syntax when calling via a function pointer, since=20
> the=20
> > > type has no concept of parameter names. - Requires some language=20
> changes=20
> > > to enable the callsite syntax=20
> > > - Argument names while not part of the ABI, are now part of the API.=
=20
> You=20
> > > cannot change the names or you will break callers.=20
> > This is sort-of inherent to the feature, but it suggests that having=20
> foreign=20
> > (member declaration) syntax for named parameters is actually a good=20
> thing.=20
>
> You can specify parameter names in the function pointer syntax...=20
>

But they are meaningless, and I don't want to try to propose we change the=
=20
type system for function pointers. You might be able to extract the names=
=20
in simple cases, but when it comes to templates, auto, and decltype it=20
could get very messy.

=20

>
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
>    Software Architect - Intel Open Source Technology Center=20
>       PGP/GPG: 0x6EF45358; fingerprint:=20
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358=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_1914_15351143.1402982298273
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, June 17, 2014 1:10:40 AM UTC-4, Thiago=
 Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Em ter 17 jun =
2014, =C3=A0s 12:43:19, David Krauss escreveu:
<br>&gt; On 2014-06-17, at 10:46 AM, Matthew Fioravante &lt;<a href=3D"java=
script:" target=3D"_blank" gdf-obfuscated-mailto=3D"R7SyU1e7rD8J" onmousedo=
wn=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javas=
cript:';return true;">fmatth...@gmail.com</a>&gt;=20
<br>wrote:
<br>&gt; &gt; The original style:
<br>&gt; &gt;=20
<br>&gt; &gt; int foo(int a, int b, string c);
<br>&gt; &gt; foo(.a =3D 0, .b =3D 1, .c =3D "Hello");
<br>&gt; &gt;=20
<br>&gt; &gt; Pros:
<br>&gt; &gt; - Very simple
<br>&gt; &gt; - No ABI changes
<br>&gt; &gt; - All legacy code immediately becomes named function enabled
<br>&gt;=20
<br>&gt; &gt; Cons:
<br>&gt; The big con is that without ABI support, there's no overloading. M=
y example
<br>&gt; wouldn't work because both rect::rect overloads would mangle to th=
e same
<br>&gt; name.
<br>
<br>Use a tag struct as a differentiator:
<br>
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;struct TopLeftBottomRig=
ht {};
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;rect(int top, int left,=
 int bottom, int right, TopLeftBottomRight =3D {})
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;struct TopLeftWidthHeig=
ht {};
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;rect(int top, int left,=
 int width, int height, TopLeftWidthHeight =3D {});
<br>
<br></blockquote><div>That's one way to do it, if we cannot come up with a =
nice naming rule.</div><div><br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;">&gt; &gt; - Cannot use named syntax when calling via a function poi=
nter, since the
<br>&gt; &gt; type has no concept of parameter names. - Requires some langu=
age changes
<br>&gt; &gt; to enable the callsite syntax
<br>&gt; &gt; - Argument names while not part of the ABI, are now part of t=
he API. You
<br>&gt; &gt; cannot change the names or you will break callers.
<br>&gt; This is sort-of inherent to the feature, but it suggests that havi=
ng foreign
<br>&gt; (member declaration) syntax for named parameters is actually a goo=
d thing.
<br>
<br>You can specify parameter names in the function pointer syntax...
<br></blockquote><div><br></div><div>But they are meaningless, and I don't =
want to try to propose we change the type system for function pointers. You=
 might be able to extract the names in simple cases, but when it comes to t=
emplates, auto, and decltype it could get very messy.</div><div><br></div><=
div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%=
3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQjCNEswDUBNCNanbu7euhq=
Ln_62FW8ag';return true;" onclick=3D"this.href=3D'http://www.google.com/url=
?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQjCNEswDUBNC=
Nanbu7euhqLn_62FW8ag';return true;">macieira.info</a> - thiago (AT) <a href=
=3D"http://kde.org" target=3D"_blank" onmousedown=3D"this.href=3D'http://ww=
w.google.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75AFQj=
CNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'http:=
//www.google.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75=
AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;">kde.org</a>
<br>&nbsp; &nbsp;Software Architect - Intel Open Source Technology Center
<br>&nbsp; &nbsp; &nbsp; PGP/GPG: 0x6EF45358; fingerprint:
<br>&nbsp; &nbsp; &nbsp; E067 918B B660 DBD1 105C &nbsp;966C 33F5 F005 6EF4=
 5358
<br>
<br></blockquote></div>

<p></p>

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

------=_Part_1914_15351143.1402982298273--

.

------=_Part_63_29705748.1403012609765
Content-Type: text/plain; charset=UTF-8


On Tuesday, 17 June 2014 05:43:28 UTC+1, David Krauss wrote:

<snip>


>  struct point {
>     int top, left;
> };
>
> struct rect {
>     point top_left, bottom_right;
>     float angle;
>
>     rect( /* struct */ { int top, left, bottom, right; }, float in_angle =
> 0 )
>         : top( top ), left( left ), bottom( bottom ), right( right ),
> angle( in_angle ) {}
>
>     rect( /* struct */ { int top, left, height, width; }, float in_angle =
> 0 )
>         : top( in_top ), left( in_left )
>         , bottom( in_top + in_width ), right( in_left + in_width )
>         , angle( in_angle ) {}
>
>     rect( /* struct */ { point top_left, point bottom_right; }, float
> in_angle = 0 )
>         : top_left( top_left ), bottom_right( bottom_right ), angle(
> in_angle ) {}
> };
>
> rect a( .top = 4, .height = 43, .left = 10, .width = 100 ); // OK
> rect b( .top_left = { 4, 43 }, .bottom_right = { 10, 100 } ); // OK
> rect c( .top_left = 4, 43, .bottom_right = 10, 100 ); // OK: (additional)
> brace elision
>
Please, no.  That could only cause confusion, as the number of actual
parameters (2) is not the number of apparent parameters (4).


>  rect d( .top = 4, 43, .bottom = 10, 100 ); // OK: initialize successive
> members.
> rect e( .top = 4, 43, 10, 100 ); // Error: ambiguous.
> rect f( 4, 43, .bottom = 10, 100 ); // OK, if poor style, the user is
> asking for it.
> rect g( .top = 4, .bottom = 47, .left = 10, .right = 110, 35_degrees ); //
> Error: mixed named and unnamed
> rect h( { .top = 4, .bottom = 47, .left = 10, .right = 110 }, 35_degrees
> ); // OK
>
>
>

--

---
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_63_29705748.1403012609765
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><DIV><BR>On Tuesday, 17 June 2014 05:43:28 UTC+1, David Kr=
auss wrote:</DIV>
<DIV>&nbsp;</DIV>
<DIV>&lt;snip&gt;</DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE style=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex=
; PADDING-LEFT: 1ex" class=3Dgmail_quote>
<DIV style=3D"WORD-WRAP: break-word">
<DIV>
<DIV><FONT face=3DCourier>struct point {</FONT></DIV>
<DIV><FONT face=3DCourier>&nbsp; &nbsp; int top, left;</FONT></DIV>
<DIV><FONT face=3DCourier>};</FONT></DIV>
<DIV><FONT face=3DCourier><BR></FONT></DIV>
<DIV><FONT face=3DCourier>struct rect {<BR>&nbsp; &nbsp; point top_left, bo=
ttom_right;</FONT></DIV>
<DIV><FONT face=3DCourier>&nbsp; &nbsp; float angle;<BR><BR>&nbsp; &nbsp; r=
ect( /* struct */ { int top, left, bottom, right; }, float in_angle =3D 0 )=
<BR>&nbsp; &nbsp; &nbsp; &nbsp; : top( top ), left( left ), bottom( bottom =
), right( right ), angle( in_angle ) {}<BR><BR></FONT></DIV>
<DIV><FONT face=3DCourier>&nbsp; &nbsp; rect( /* struct */ { int top, left,=
 height, width; }, float in_angle =3D 0 )<BR>&nbsp; &nbsp; &nbsp; &nbsp; : =
top( in_top ), left( in_left )<BR>&nbsp; &nbsp; &nbsp; &nbsp; , bottom( in_=
top + in_width ), right( in_left + in_width )</FONT></DIV>
<DIV><FONT face=3DCourier>&nbsp; &nbsp; &nbsp; &nbsp; , angle( in_angle ) {=
}<BR><BR>&nbsp; &nbsp; rect( /* struct */ { point top_left, point bottom_ri=
ght; }, float in_angle =3D 0 )<BR>&nbsp; &nbsp; &nbsp; &nbsp; : top_left( t=
op_left ), bottom_right( bottom_right ),&nbsp;angle( in_angle&nbsp;) {}<BR>=
};<BR><BR>rect a( .top =3D 4, .height =3D 43, .left =3D 10, .width =3D 100 =
); // OK<BR>rect b( .top_left =3D { 4, 43 }, .bottom_right =3D { 10, 100 } =
); // OK<BR>rect c( .top_left =3D 4, 43, .bottom_right =3D 10, 100 ); // OK=
: (additional) brace elision<BR></FONT></DIV></DIV></DIV></BLOCKQUOTE>
<DIV>Please, no.&nbsp; That could only cause confusion, as the number of ac=
tual parameters (2) is not the number of apparent parameters (4).</DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE style=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex=
; PADDING-LEFT: 1ex" class=3Dgmail_quote>
<DIV style=3D"WORD-WRAP: break-word">
<DIV>
<DIV><SPAN style=3D"FONT-FAMILY: Courier">rect d( .top =3D 4, 43, .bottom =
=3D 10, 100 ); // OK: initialize successive members.</SPAN><BR style=3D"FON=
T-FAMILY: Courier"><FONT face=3DCourier>rect e( .top =3D 4, 43, 10, 100 ); =
// Error: ambiguous.<BR></FONT><SPAN style=3D"FONT-FAMILY: Courier">rect f(=
 4, 43, .bottom =3D 10, 100 ); // OK, if poor style, the user is asking for=
 it.</SPAN><BR style=3D"FONT-FAMILY: Courier"><FONT face=3DCourier>rect g( =
..top =3D 4, .bottom =3D 47, .left =3D 10, .right =3D 110, 35_degrees ); // =
Error: mixed named and unnamed<BR>rect h( { .top =3D 4, .bottom =3D 47, .le=
ft =3D 10, .right =3D 110 }, 35_degrees ); // OK<BR></FONT><BR></DIV></DIV>
<DIV><BR></DIV></DIV></BLOCKQUOTE></div>

<p></p>

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

------=_Part_63_29705748.1403012609765--

.

------=_Part_2759_8892083.1403017149445
Content-Type: text/plain; charset=UTF-8

As I'm working on the paper and thinking about the details of the proposal,
I've found a few issues to wrestle with.

The major difference between aggregate initialization and a set of what I
call in the paper compiler generated "aggregate member constructors":

Aggregates can be left in an uninitialized state by not specifying an
initializer. If we drop aggregate initialization in favor of constructors,
we still need to support this behavior.


Named function parameters using structs chicken and egg problem:

If we had named function params, aka:

int foo(int a, int b, int c);
foo(.a = 1, .b = 2, .c = 4);

Then having designated initializers for structs would just fall out from
this in the constructors.

If we introduce designated initializers first, then named function
parameters are derived from that. I'm falling more and more into the second
camp because as I think about it, separating positional and named arguments
seems to make a lot of sense.

The names of the positional arguments stay out of the source level API. If
we go with the first approach, all of the sudden the function names
everyone is using in legacy code become source level API. This is not
something I'd want to wrestle with in a large legacy code base. Instead, we
can control our interfaces more explicitly.


--

---
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_2759_8892083.1403017149445
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">As I'm working on the paper and thinking about the details=
 of the proposal, I've found a few issues to wrestle with.<br><br>The major=
 difference between aggregate initialization and a set of what I call in th=
e paper compiler generated "aggregate member constructors":<br><br>Aggregat=
es can be left in an uninitialized state by not specifying an initializer. =
If we drop aggregate initialization in favor of constructors, we still need=
 to support this behavior.<br><br><br>Named function parameters using struc=
ts chicken and egg problem:<br><br>If we had named function params, aka:<br=
><br>int foo(int a, int b, int c);<br>foo(.a =3D 1, .b =3D 2, .c =3D 4);<br=
><br>Then having designated initializers for structs would just fall out fr=
om this in the constructors.<br><br>If we introduce designated initializers=
 first, then named function parameters are derived from that. I'm falling m=
ore and more into the second camp because as I think about it, separating p=
ositional and named arguments seems to make a lot of sense. <br><br>The nam=
es of the positional arguments stay out of the source level API. If we go w=
ith the first approach, all of the sudden the function names everyone is us=
ing in legacy code become source level API. This is not something I'd want =
to wrestle with in a large legacy code base. Instead, we can control our in=
terfaces more explicitly. <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_2759_8892083.1403017149445--

.

--Apple-Mail=_402A16AF-E43E-4EAC-B94A-03AE94118D62
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-06-17, at 10:59 PM, Matthew Fioravante <fmatthew5876@gmail.com> wro=
te:

> As I'm working on the paper and thinking about the details of the proposa=
l, I've found a few issues to wrestle with.
>=20
> The major difference between aggregate initialization and a set of what I=
 call in the paper compiler generated "aggregate member constructors":
>=20
> Aggregates can be left in an uninitialized state by not specifying an ini=
tializer. If we drop aggregate initialization in favor of constructors, we =
still need to support this behavior.

Who is "we"? Surely you don't mean dropping it from the standard, but you'r=
e just considering the case when the user is migrating a class from from ag=
gregate to constructor?

Hmm. Checking the draft:
> First, this syntax is yet another special case inherited for C compatibil=
ity. These compatibility cases complicate the standard and the learning cur=
ve for C++ developers. It would be better if this feature could be reimplem=
ented using already existing C++ rules and mechanisms and still retain C co=
mpatibility.
>=20

This seems to be veering away from the problem statement. "Newer would be b=
etter" is not much of a motivation. You need to clearly state what's broken=
 before going down this path. For what it's worth, aggregate initialization=
 has been maintained just as carefully as the rest of the language.

> Named function parameters using structs chicken and egg problem:
>=20
> If we had named function params, aka:
>=20
> int foo(int a, int b, int c);
> foo(.a =3D 1, .b =3D 2, .c =3D 4);
>=20
> Then having designated initializers for structs would just fall out from =
this in the constructors.
>=20
> If we introduce designated initializers first, then named function parame=
ters are derived from that. I'm falling more and more into the second camp =
because as I think about it, separating positional and named arguments seem=
s to make a lot of sense.=20

This seems to be the same as what you've been saying throughout this thread=
.. Is there a problem or are you affirming the previous ideas? I'm a little =
confused. Also I don't see how this relates to what's in the posted draft s=
o far.

--=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=_402A16AF-E43E-4EAC-B94A-03AE94118D62
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 10:59 PM, Matthew Fioravante &lt;<a href=3D"mailto:fm=
atthew5876@gmail.com">fmatthew5876@gmail.com</a>&gt; wrote:</div><br class=
=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr">A=
s I'm working on the paper and thinking about the details of the proposal, =
I've found a few issues to wrestle with.<br><br>The major difference betwee=
n aggregate initialization and a set of what I call in the paper compiler g=
enerated "aggregate member constructors":<br><br>Aggregates can be left in =
an uninitialized state by not specifying an initializer. If we drop aggrega=
te initialization in favor of constructors, we still need to support this b=
ehavior.<br></div></blockquote><div><br></div><div>Who is &ldquo;we&rdquo;?=
 Surely you don&rsquo;t mean dropping it from the standard, but you&rsquo;r=
e just considering the case when the user is migrating a class from from ag=
gregate to constructor?</div><div><br></div><div>Hmm. Checking the draft:</=
div><div><blockquote type=3D"cite"><p>First, this syntax is yet another <em=
>special case</em> inherited for C
compatibility. These compatibility cases complicate the standard
and the learning
curve for C++ developers. It would be better if this feature could
be reimplemented using already existing C++ rules and mechanisms
and still retain C compatibility.</p></blockquote></div><div>This seems to =
be veering away from the problem statement. &ldquo;Newer would be better&rd=
quo; is not much of a motivation. You need to clearly state what&rsquo;s br=
oken before going down this path. For what it&rsquo;s worth, aggregate init=
ialization has been maintained just as carefully as the rest of the languag=
e.</div><br><blockquote type=3D"cite"><div dir=3D"ltr">Named function param=
eters using structs chicken and egg problem:<br><br>If we had named functio=
n params, aka:<br><br>int foo(int a, int b, int c);<br>foo(.a =3D 1, .b =3D=
 2, .c =3D 4);<br><br>Then having designated initializers for structs would=
 just fall out from this in the constructors.<br><br>If we introduce design=
ated initializers first, then named function parameters are derived from th=
at. I'm falling more and more into the second camp because as I think about=
 it, separating positional and named arguments seems to make a lot of sense=
.. <br></div></blockquote><div><br></div><div>This seems to be the same as w=
hat you&rsquo;ve been saying throughout this thread. Is there a problem or =
are you affirming the previous ideas? I&rsquo;m a little confused. Also I d=
on&rsquo;t see how this relates to what&rsquo;s in the posted draft so far.=
</div></div><br></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=_402A16AF-E43E-4EAC-B94A-03AE94118D62--

.

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



On Tuesday, June 17, 2014 11:21:51 AM UTC-4, David Krauss wrote:
>
>
> On 2014=E2=80=9306=E2=80=9317, at 10:59 PM, Matthew Fioravante <fmatth...=
@gmail.com=20
> <javascript:>> wrote:
>
> As I'm working on the paper and thinking about the details of the=20
> proposal, I've found a few issues to wrestle with.
>
> The major difference between aggregate initialization and a set of what I=
=20
> call in the paper compiler generated "aggregate member constructors":
>
> Aggregates can be left in an uninitialized state by not specifying an=20
> initializer. If we drop aggregate initialization in favor of constructors=
,=20
> we still need to support this behavior.
>
>
> Who is =E2=80=9Cwe=E2=80=9D? Surely you don=E2=80=99t mean dropping it fr=
om the standard, but=20
> you=E2=80=99re just considering the case when the user is migrating a cla=
ss from=20
> from aggregate to constructor?
>
> Hmm. Checking the draft:
>
> First, this syntax is yet another *special case* inherited for C=20
> compatibility. These compatibility cases complicate the standard and the=
=20
> learning curve for C++ developers. It would be better if this feature cou=
ld=20
> be reimplemented using already existing C++ rules and mechanisms and stil=
l=20
> retain C compatibility.
>
> This seems to be veering away from the problem statement. =E2=80=9CNewer =
would be=20
> better=E2=80=9D is not much of a motivation. You need to clearly state wh=
at=E2=80=99s=20
> broken before going down this path. For what it=E2=80=99s worth, aggregat=
e=20
> initialization has been maintained just as carefully as the rest of the=
=20
> language.
>

The idea is that if aggregate initialization for class types can be=20
completely reproduced by compiler generated constructors, we don't actually=
=20
need it. This is a side question and not too important.=20

>
> Named function parameters using structs chicken and egg problem:
>
> If we had named function params, aka:
>
> int foo(int a, int b, int c);
> foo(.a =3D 1, .b =3D 2, .c =3D 4);
>
> Then having designated initializers for structs would just fall out from=
=20
> this in the constructors.
>
> If we introduce designated initializers first, then named function=20
> parameters are derived from that. I'm falling more and more into the seco=
nd=20
> camp because as I think about it, separating positional and named argumen=
ts=20
> seems to make a lot of sense.=20
>
>
> This seems to be the same as what you=E2=80=99ve been saying throughout t=
his=20
> thread. Is there a problem or are you affirming the previous ideas? I=E2=
=80=99m a=20
> little confused. Also I don=E2=80=99t see how this relates to what=E2=80=
=99s in the posted=20
> draft so far.
>
>
I have not written about named arguments yet in my draft. I'm mostly=20
thinking out loud. It seems like everyone here is in the struct argument=20
passing camp. If anyone has strong opinions either way, I'd love to hear=20
it.=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_457_19075104.1403020369085
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, June 17, 2014 11:21:51 AM UTC-4, David=
 Krauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"wo=
rd-wrap:break-word"><br><div><div>On 2014=E2=80=9306=E2=80=9317, at 10:59 P=
M, Matthew Fioravante &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obf=
uscated-mailto=3D"sp4QVwP-39MJ" onmousedown=3D"this.href=3D'javascript:';re=
turn true;" onclick=3D"this.href=3D'javascript:';return true;">fmatth...@gm=
ail.com</a>&gt; wrote:</div><br><blockquote type=3D"cite"><div dir=3D"ltr">=
As I'm working on the paper and thinking about the details of the proposal,=
 I've found a few issues to wrestle with.<br><br>The major difference betwe=
en aggregate initialization and a set of what I call in the paper compiler =
generated "aggregate member constructors":<br><br>Aggregates can be left in=
 an uninitialized state by not specifying an initializer. If we drop aggreg=
ate initialization in favor of constructors, we still need to support this =
behavior.<br></div></blockquote><div><br></div><div>Who is =E2=80=9Cwe=E2=
=80=9D? Surely you don=E2=80=99t mean dropping it from the standard, but yo=
u=E2=80=99re just considering the case when the user is migrating a class f=
rom from aggregate to constructor?</div><div><br></div><div>Hmm. Checking t=
he draft:</div><div><blockquote type=3D"cite"><p>First, this syntax is yet =
another <i>special case</i> inherited for C
compatibility. These compatibility cases complicate the standard
and the learning
curve for C++ developers. It would be better if this feature could
be reimplemented using already existing C++ rules and mechanisms
and still retain C compatibility.</p></blockquote></div><div>This seems to =
be veering away from the problem statement. =E2=80=9CNewer would be better=
=E2=80=9D is not much of a motivation. You need to clearly state what=E2=80=
=99s broken before going down this path. For what it=E2=80=99s worth, aggre=
gate initialization has been maintained just as carefully as the rest of th=
e language.</div></div></div></blockquote><div><br>The idea is that if aggr=
egate initialization for class types can be completely reproduced by compil=
er generated constructors, we don't actually need it. This is a side questi=
on and not too important. <br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div style=3D"word-wrap:break-word"><div><br><blockquote type=3D"cite=
"><div dir=3D"ltr">Named function parameters using structs chicken and egg =
problem:<br><br>If we had named function params, aka:<br><br>int foo(int a,=
 int b, int c);<br>foo(.a =3D 1, .b =3D 2, .c =3D 4);<br><br>Then having de=
signated initializers for structs would just fall out from this in the cons=
tructors.<br><br>If we introduce designated initializers first, then named =
function parameters are derived from that. I'm falling more and more into t=
he second camp because as I think about it, separating positional and named=
 arguments seems to make a lot of sense. <br></div></blockquote><div><br></=
div><div>This seems to be the same as what you=E2=80=99ve been saying throu=
ghout this thread. Is there a problem or are you affirming the previous ide=
as? I=E2=80=99m a little confused. Also I don=E2=80=99t see how this relate=
s to what=E2=80=99s in the posted draft so far.</div></div><br></div></bloc=
kquote><div><br>I have not written about named arguments yet in my draft. I=
'm mostly thinking out loud. It seems like everyone here is in the struct a=
rgument passing camp. If anyone has strong opinions either way, I'd love to=
 hear it. <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_457_19075104.1403020369085--

.