------=_Part_155_748555786.1461938131533
Content-Type: multipart/alternative;
 boundary="----=_Part_156_90138463.1461938131533"

------=_Part_156_90138463.1461938131533
Content-Type: text/plain; charset=UTF-8

A random idea that pops in my head everytime I think about EDSLs.

Let's assume that we have a complexity namespace in which we define symbols
such as O, log, n, k, etc... to make a complexity EDSL.
The symbols are all short and might have another meaning outside of the
complexity namespace, so a using namespace complexity
is out of the question when one wants to create a complexity expression,
but prepending the namespace name before every element hinders
readbility. One idea would be to have namespaced expressions of the
following form;

auto comp = complexity::{ O(n * log(n)) };

In the expression above, the symbols O, log and n would be looked up into
the complexity namespace first as if it was equivalent to the
following expression:

auto comp = [] {
    using namespace complexity;
    return O(n * log(n));
}

I don't think such a feature has much value outside of this kind of EDSL
though, but it would allow to easily form an expression with elements
of a namespace that is not needed later without hindering readability. The
current simple solution would be to wrap the lambda into a macro,
which isn't really sexy.

Any additional thoughts?

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

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

<div dir=3D"ltr">A random idea that pops in my head everytime I think about=
 EDSLs.<br><br>Let&#39;s assume that we have a <span style=3D"font-family: =
courier new,monospace;">complexity</span> namespace in which we define symb=
ols such as <span style=3D"font-family: courier new,monospace;">O</span>, <=
span style=3D"font-family: courier new,monospace;">log</span>, <span style=
=3D"font-family: courier new,monospace;">n</span>, <span style=3D"font-fami=
ly: courier new,monospace;">k</span>, etc... to make a complexity EDSL.<br>=
The symbols are all short and might have another meaning outside of the <sp=
an style=3D"font-family: courier new,monospace;">complexity</span> namespac=
e, so a <span style=3D"font-family: courier new,monospace;">using namespace=
 complexity</span><br>is out of the question when one wants to create a com=
plexity expression, but prepending the namespace name before every element =
hinders<br>readbility. One idea would be to have namespaced expressions of =
the following form;<br><br><div style=3D"margin-left: 40px;"><span style=3D=
"font-family: courier new,monospace;">auto comp =3D complexity::{ O(n * log=
(n)) };<br></span></div><br>In the expression above, the symbols <span styl=
e=3D"font-family: courier new,monospace;">O</span>, <span style=3D"font-fam=
ily: courier new,monospace;">log</span> and <span style=3D"font-family: cou=
rier new,monospace;">n</span> would be looked up into the <span style=3D"fo=
nt-family: courier new,monospace;">complexity</span> namespace first as if =
it was equivalent to the<br>following expression:<br><br><div style=3D"marg=
in-left: 40px;"><span style=3D"font-family: courier new,monospace;">auto co=
mp =3D [] {<br>=C2=A0=C2=A0=C2=A0 using namespace complexity;<br>=C2=A0=C2=
=A0=C2=A0 return O(n * log(n));<br>}<br></span></div><br>I don&#39;t think =
such a feature has much value outside of this kind of EDSL though, but it w=
ould allow to easily form an expression with elements<br>of a namespace tha=
t is not needed later without hindering readability. The current simple sol=
ution would be to wrap the lambda into a macro,<br>which isn&#39;t really s=
exy.<br><br>Any additional thoughts?<br><br></div>

<p></p>

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

------=_Part_156_90138463.1461938131533--
------=_Part_155_748555786.1461938131533--

.

------=_Part_380_2027743963.1461947235717
Content-Type: multipart/alternative;
 boundary="----=_Part_381_2025122705.1461947235717"

------=_Part_381_2025122705.1461947235717
Content-Type: text/plain; charset=UTF-8

On Friday, April 29, 2016 at 9:55:31 AM UTC-4, Morwenn wrote:
>
> A random idea that pops in my head everytime I think about EDSLs.
>
> Let's assume that we have a complexity namespace in which we define
> symbols such as O, log, n, k, etc... to make a complexity EDSL.
> The symbols are all short and might have another meaning outside of the
> complexity namespace, so a using namespace complexity
> is out of the question when one wants to create a complexity expression,
> but prepending the namespace name before every element hinders
> readbility. One idea would be to have namespaced expressions of the
> following form;
>
> auto comp = complexity::{ O(n * log(n)) };
>

Why use `::` and `{}` here? A namespace followed by an open-paren is not a
valid expression, so it seems to me that using that would be better. It
would also help preserve `{}` in expressions to mean "initialize" (or
"function body"):

auto comp = complexity(O(n * log(n));

In the expression above, the symbols O, log and n would be looked up into
> the complexity namespace first as if it was equivalent to the
> following expression:
>
> auto comp = [] {
>     using namespace complexity;
>     return O(n * log(n));
> }
>

I'll assume you meant to add an extra `()` to the end of that. Unless you
really mean for `comp` to be a lambda function rather than a value.

Also, this lambda is not correct. It should use `decltype(auto)` as the
return type, to prevent the creation of an extraneous value type/copy.

Things like that are why expressing behavior in terms of lambda
transformations is dangerous. It's better to just express how it should
behave directly: that function lookup within the enclosed expression will
take place as though it were in the bounds of a `using namespace X`
directive.

The lambda is just added noise to that definition.


> I don't think such a feature has much value outside of this kind of EDSL
> though, but it would allow to easily form an expression with elements
> of a namespace that is not needed later without hindering readability. The
> current simple solution would be to wrap the lambda into a macro,
> which isn't really sexy.
>
> Any additional thoughts?
>

I've used two EDSLs in C++: Boost.Spirit and Luabind. In both cases, the
actual EDSL expressions *dominated* the source code, relative to a `using
namespace X`. Most of the functions that use them had dozens of lines of
code using that EDSL.

I'm sure it's possible that other EDSLs lend themselves to small, one-off
expressions like the above. But how common are these? It's been my
experience that either your function uses the EDSL or it doesn't.

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

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

<div dir=3D"ltr">On Friday, April 29, 2016 at 9:55:31 AM UTC-4, Morwenn wro=
te:<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">A random i=
dea that pops in my head everytime I think about EDSLs.<br><br>Let&#39;s as=
sume that we have a <span style=3D"font-family:courier new,monospace">compl=
exity</span> namespace in which we define symbols such as <span style=3D"fo=
nt-family:courier new,monospace">O</span>, <span style=3D"font-family:couri=
er new,monospace">log</span>, <span style=3D"font-family:courier new,monosp=
ace">n</span>, <span style=3D"font-family:courier new,monospace">k</span>, =
etc... to make a complexity EDSL.<br>The symbols are all short and might ha=
ve another meaning outside of the <span style=3D"font-family:courier new,mo=
nospace">complexity</span> namespace, so a <span style=3D"font-family:couri=
er new,monospace">using namespace complexity</span><br>is out of the questi=
on when one wants to create a complexity expression, but prepending the nam=
espace name before every element hinders<br>readbility. One idea would be t=
o have namespaced expressions of the following form;<br><br><div style=3D"m=
argin-left:40px"><span style=3D"font-family:courier new,monospace">auto com=
p =3D complexity::{ O(n * log(n)) };<br></span></div></div></blockquote><di=
v><br>Why use `::` and `{}` here? A namespace followed by an open-paren is =
not a valid expression, so it seems to me that using that would be better. =
It would also help preserve `{}` in expressions to mean &quot;initialize&qu=
ot; (or &quot;function body&quot;):<br><br><div class=3D"prettyprint" style=
=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187);=
 border-style: solid; border-width: 1px; word-wrap: break-word;"><code clas=
s=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;=
" class=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> comp </span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> complexity</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">O</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">n </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">*</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> log</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">n</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">));</span></div></code></div><br></div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div style=3D"margin-left=
:40px"><span style=3D"font-family:courier new,monospace"></span></div>In th=
e expression above, the symbols <span style=3D"font-family:courier new,mono=
space">O</span>, <span style=3D"font-family:courier new,monospace">log</spa=
n> and <span style=3D"font-family:courier new,monospace">n</span> would be =
looked up into the <span style=3D"font-family:courier new,monospace">comple=
xity</span> namespace first as if it was equivalent to the<br>following exp=
ression:<br><br><div style=3D"margin-left:40px"><span style=3D"font-family:=
courier new,monospace">auto comp =3D [] {<br>=C2=A0=C2=A0=C2=A0 using names=
pace complexity;<br>=C2=A0=C2=A0=C2=A0 return O(n * log(n));<br>}<br></span=
></div></div></blockquote><div><br>I&#39;ll assume you meant to add an extr=
a `()` to the end of that. Unless you really mean for `comp` to be a lambda=
 function rather than a value.<br><br>Also, this lambda is not correct. It =
should use `decltype(auto)` as the return type, to prevent the creation of =
an extraneous value type/copy.<br><br>Things like that are why expressing b=
ehavior in terms of lambda transformations is dangerous. It&#39;s better to=
 just express how it should behave directly: that function lookup within th=
e enclosed expression will take place as though it were in the bounds of a =
`using namespace X` directive.<br><br>The lambda is just added noise to tha=
t definition.<br>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;"><div dir=3D"ltr"><div style=3D"margin-left:40px"><span style=3D"font-fam=
ily:courier new,monospace"></span></div>I don&#39;t think such a feature ha=
s much value outside of this kind of EDSL though, but it would allow to eas=
ily form an expression with elements<br>of a namespace that is not needed l=
ater without hindering readability. The current simple solution would be to=
 wrap the lambda into a macro,<br>which isn&#39;t really sexy.<br><br>Any a=
dditional thoughts?<br></div></blockquote><div><br>I&#39;ve used two EDSLs =
in C++: Boost.Spirit and Luabind. In both cases, the actual EDSL expression=
s <i>dominated</i> the source code, relative to a `using namespace X`. Most=
 of the functions that use them had dozens of lines of code using that EDSL=
..<br><br>I&#39;m sure it&#39;s possible that other EDSLs lend themselves to=
 small, one-off expressions like the above. But how common are these? It&#3=
9;s been my experience that either your function uses the EDSL or it doesn&=
#39;t.<br></div></div>

<p></p>

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

------=_Part_381_2025122705.1461947235717--
------=_Part_380_2027743963.1461947235717--

.

------=_Part_4212_279572804.1461947869841
Content-Type: multipart/alternative;
 boundary="----=_Part_4213_1323151432.1461947869841"

------=_Part_4213_1323151432.1461947869841
Content-Type: text/plain; charset=UTF-8


>
> using namespace complexity;
>

This doesn't quite do what you want; what you want is for complexity to
have *first *priority, not *equal *priority. I think the syntactic
transformation you want is a bunch of using declarations instead of a
single namespace directive. For example, if you have both ::log and
::complexity::log, you want lookup to find the latter instead of throwing
an error.

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

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

<div dir=3D"ltr"><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-lef=
t: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote">=
<span style=3D"font-family: courier new,monospace;">using namespace complex=
ity;</span><br></blockquote><br>This doesn&#39;t quite do what you want; wh=
at you want is for <span style=3D"font-family: courier new,monospace;">comp=
lexity</span><span style=3D"font-family: courier new,monospace;"></span> to=
 have <i>first </i>priority, not <i>equal </i>priority.
 I think the syntactic transformation you want is a bunch of using=20
declarations instead of a single namespace directive. For example, if you h=
ave both <span style=3D"font-family: courier new,monospace;">::log</span> a=
nd <span style=3D"font-family: courier new,monospace;">::complexity::log</s=
pan>, you want lookup to find the latter instead of throwing an error.<br><=
/div>

<p></p>

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

------=_Part_4213_1323151432.1461947869841--
------=_Part_4212_279572804.1461947869841--

.

------=_Part_647_1814352992.1461950780180
Content-Type: multipart/alternative;
 boundary="----=_Part_648_1069994365.1461950780180"

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

Le vendredi 29 avril 2016 18:27:15 UTC+2, Nicol Bolas a =C3=A9crit :
>
> On Friday, April 29, 2016 at 9:55:31 AM UTC-4, Morwenn wrote:
>>
>> A random idea that pops in my head everytime I think about EDSLs.
>>
>> Let's assume that we have a complexity namespace in which we define=20
>> symbols such as O, log, n, k, etc... to make a complexity EDSL.
>> The symbols are all short and might have another meaning outside of the=
=20
>> complexity namespace, so a using namespace complexity
>> is out of the question when one wants to create a complexity expression,=
=20
>> but prepending the namespace name before every element hinders
>> readbility. One idea would be to have namespaced expressions of the=20
>> following form;
>>
>> auto comp =3D complexity::{ O(n * log(n)) };
>>
>
> Why use `::` and `{}` here? A namespace followed by an open-paren is not =
a=20
> valid expression, so it seems to me that using that would be better. It=
=20
> would also help preserve `{}` in expressions to mean "initialize" (or=20
> "function body"):=20
>

> auto comp =3D complexity(O(n * log(n));
>
> The syntax was made up on the fly, I did not think it through. I guess I=
=20
liked having :: to show that we're peeking inside a namespace, but that's=
=20
pretty much all there was to it.
=20

> In the expression above, the symbols O, log and n would be looked up into=
=20
>> the complexity namespace first as if it was equivalent to the
>> following expression:
>>
>> auto comp =3D [] {
>>     using namespace complexity;
>>     return O(n * log(n));
>> }
>>
>
> I'll assume you meant to add an extra `()` to the end of that. Unless you=
=20
> really mean for `comp` to be a lambda function rather than a value.
> =20
>
Right, I was a bit in a hurry, but I meant to make that an IIFE.=20
=20

> Also, this lambda is not correct. It should use `decltype(auto)` as the=
=20
> return type, to prevent the creation of an extraneous value type/copy.
>
> Things like that are why expressing behavior in terms of lambda=20
> transformations is dangerous. It's better to just express how it should=
=20
> behave directly: that function lookup within the enclosed expression will=
=20
> take place as though it were in the bounds of a `using namespace X`=20
> directive.
>
> The lambda is just added noise to that definition.
> =20
>
True again. But I'm just as bad at formulating things in decent English. I=
=20
thought an example would help :/
=20

> I don't think such a feature has much value outside of this kind of EDSL=
=20
>> though, but it would allow to easily form an expression with elements
>> of a namespace that is not needed later without hindering readability.=
=20
>> The current simple solution would be to wrap the lambda into a macro,
>> which isn't really sexy.
>>
>> Any additional thoughts?
>>
>
> I've used two EDSLs in C++: Boost.Spirit and Luabind. In both cases, the=
=20
> actual EDSL expressions *dominated* the source code, relative to a `using=
=20
> namespace X`. Most of the functions that use them had dozens of lines of=
=20
> code using that EDSL.
>
> I'm sure it's possible that other EDSLs lend themselves to small, one-off=
=20
> expressions like the above. But how common are these? It's been my=20
> experience that either your function uses the EDSL or it doesn't.
>

I tend to agree. On the other hand, I often chose not to try to write such=
=20
small EDSL *because* there wasn't an obvious way to use them like that=20
without too much boilerplate. I can't tell whether such EDSLs would be more=
=20
common or not with such a feature. Well, that's why I'm raising the idea=20
here in the end :)

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/80f0d727-790c-426a-8523-5994cba77642%40isocpp.or=
g.

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

<div dir=3D"ltr">Le vendredi 29 avril 2016 18:27:15 UTC+2, Nicol Bolas a =
=C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">On Friday, April 29, 2016 at 9:55:31 AM UTC-4, Morwenn wrote:<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">A random idea that pops in m=
y head everytime I think about EDSLs.<br><br>Let&#39;s assume that we have =
a <span style=3D"font-family:courier new,monospace">complexity</span> names=
pace in which we define symbols such as <span style=3D"font-family:courier =
new,monospace">O</span>, <span style=3D"font-family:courier new,monospace">=
log</span>, <span style=3D"font-family:courier new,monospace">n</span>, <sp=
an style=3D"font-family:courier new,monospace">k</span>, etc... to make a c=
omplexity EDSL.<br>The symbols are all short and might have another meaning=
 outside of the <span style=3D"font-family:courier new,monospace">complexit=
y</span> namespace, so a <span style=3D"font-family:courier new,monospace">=
using namespace complexity</span><br>is out of the question when one wants =
to create a complexity expression, but prepending the namespace name before=
 every element hinders<br>readbility. One idea would be to have namespaced =
expressions of the following form;<br><br><div style=3D"margin-left:40px"><=
span style=3D"font-family:courier new,monospace">auto comp =3D complexity::=
{ O(n * log(n)) };<br></span></div></div></blockquote><div><br>Why use `::`=
 and `{}` here? A namespace followed by an open-paren is not a valid expres=
sion, so it seems to me that using that would be better. It would also help=
 preserve `{}` in expressions to mean &quot;initialize&quot; (or &quot;func=
tion body&quot;): <br></div></div></blockquote><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;"><div dir=3D"ltr"><div><br><div style=3D"background-color:r=
gb(250,250,250);border-color:rgb(187,187,187);border-style:solid;border-wid=
th:1px;word-wrap:break-word"><code><div><span style=3D"color:#008">auto</sp=
an><span style=3D"color:#000"> comp </span><span style=3D"color:#660">=3D</=
span><span style=3D"color:#000"> complexity</span><span style=3D"color:#660=
">(</span><span style=3D"color:#000">O</span><span style=3D"color:#660">(</=
span><span style=3D"color:#000">n </span><span style=3D"color:#660">*</span=
><span style=3D"color:#000"> log</span><span style=3D"color:#660">(</span><=
span style=3D"color:#000">n</span><span style=3D"color:#660">));</span></di=
v></code></div><br></div></div></blockquote><div>The syntax was made up on =
the fly, I did not think it through. I guess I liked having <span style=3D"=
font-family: courier new,monospace;">::</span> to show that we&#39;re peeki=
ng inside a namespace, but that&#39;s pretty much all there was to it.<br>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0=
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div sty=
le=3D"margin-left:40px"><span style=3D"font-family:courier new,monospace"><=
/span></div>In the expression above, the symbols <span style=3D"font-family=
:courier new,monospace">O</span>, <span style=3D"font-family:courier new,mo=
nospace">log</span> and <span style=3D"font-family:courier new,monospace">n=
</span> would be looked up into the <span style=3D"font-family:courier new,=
monospace">complexity</span> namespace first as if it was equivalent to the=
<br>following expression:<br><br><div style=3D"margin-left:40px"><span styl=
e=3D"font-family:courier new,monospace">auto comp =3D [] {<br>=C2=A0=C2=A0=
=C2=A0 using namespace complexity;<br>=C2=A0=C2=A0=C2=A0 return O(n * log(n=
));<br>}<br></span></div></div></blockquote><div><br>I&#39;ll assume you me=
ant to add an extra `()` to the end of that. Unless you really mean for `co=
mp` to be a lambda function rather than a value.<br>=C2=A0</div></div></blo=
ckquote><div>Right, I was a bit in a hurry, but I meant to make that an IIF=
E. <br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
<div dir=3D"ltr"><div>Also, this lambda is not correct. It should use `decl=
type(auto)` as the return type, to prevent the creation of an extraneous va=
lue type/copy.<br><br>Things like that are why expressing behavior in terms=
 of lambda transformations is dangerous. It&#39;s better to just express ho=
w it should behave directly: that function lookup within the enclosed expre=
ssion will take place as though it were in the bounds of a `using namespace=
 X` directive.<br><br>The lambda is just added noise to that definition.<br=
>=C2=A0<br></div></div></blockquote><div>True again. But I&#39;m just as ba=
d at formulating things in decent English. I thought an example would help =
:/<br>=C2=A0</div><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"><div></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-=
left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><d=
iv style=3D"margin-left:40px"><span style=3D"font-family:courier new,monosp=
ace"></span></div>I don&#39;t think such a feature has much value outside o=
f this kind of EDSL though, but it would allow to easily form an expression=
 with elements<br>of a namespace that is not needed later without hindering=
 readability. The current simple solution would be to wrap the lambda into =
a macro,<br>which isn&#39;t really sexy.<br><br>Any additional thoughts?<br=
></div></blockquote><div><br>I&#39;ve used two EDSLs in C++: Boost.Spirit a=
nd Luabind. In both cases, the actual EDSL expressions <i>dominated</i> the=
 source code, relative to a `using namespace X`. Most of the functions that=
 use them had dozens of lines of code using that EDSL.<br><br>I&#39;m sure =
it&#39;s possible that other EDSLs lend themselves to small, one-off expres=
sions like the above. But how common are these? It&#39;s been my experience=
 that either your function uses the EDSL or it doesn&#39;t.<br></div></div>=
</blockquote><div><br>I tend to agree. On the other hand, I often chose not=
 to try to write such small EDSL <i>because</i> there wasn&#39;t an obvious=
 way to use them like that without too much boilerplate. I can&#39;t tell w=
hether such EDSLs would be more common or not with such a feature. Well, th=
at&#39;s why I&#39;m raising the idea here in the end :)<br></div></div>

<p></p>

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

------=_Part_648_1069994365.1461950780180--
------=_Part_647_1814352992.1461950780180--

.

------=_Part_6373_629101684.1461950872756
Content-Type: multipart/alternative;
 boundary="----=_Part_6374_1269310976.1461950872756"

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

Le vendredi 29 avril 2016 18:37:50 UTC+2, Chris Hallock a =C3=A9crit :
>
> using namespace complexity;
>>
>
> This doesn't quite do what you want; what you want is for complexity to=
=20
> have *first *priority, not *equal *priority. I think the syntactic=20
> transformation you want is a bunch of using declarations instead of a=20
> single namespace directive. For example, if you have both ::log and=20
> ::complexity::log, you want lookup to find the latter instead of throwing=
=20
> an error.
>

Yup, I didn't think the details through since it was just a random idea=20
(raising interest first was the idea). I'm glad that the concept and intent=
=20
are clear enough in people's mind though.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/ee27da70-3362-483d-a9e1-459a7cff85db%40isocpp.or=
g.

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

<div dir=3D"ltr">Le vendredi 29 avril 2016 18:37:50 UTC+2, Chris Hallock a =
=C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb=
(204,204,204);padding-left:1ex" class=3D"gmail_quote"><span style=3D"font-f=
amily:courier new,monospace">using namespace complexity;</span><br></blockq=
uote><br>This doesn&#39;t quite do what you want; what you want is for <spa=
n style=3D"font-family:courier new,monospace">complexity</span><span style=
=3D"font-family:courier new,monospace"></span> to have <i>first </i>priorit=
y, not <i>equal </i>priority.
 I think the syntactic transformation you want is a bunch of using=20
declarations instead of a single namespace directive. For example, if you h=
ave both <span style=3D"font-family:courier new,monospace">::log</span> and=
 <span style=3D"font-family:courier new,monospace">::complexity::log</span>=
, you want lookup to find the latter instead of throwing an error.<br></div=
></blockquote><div><br>Yup, I didn&#39;t think the details through since it=
 was just a random idea (raising interest first was the idea). I&#39;m glad=
 that the concept and intent are clear enough in people&#39;s mind though.<=
br></div></div>

<p></p>

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

------=_Part_6374_1269310976.1461950872756--
------=_Part_6373_629101684.1461950872756--

.

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

Assuming 'n' is a special variable with a special type, ADL already does
what you need.

On 29 April 2016 at 14:55, Morwenn <morwenn29@gmail.com> wrote:

> A random idea that pops in my head everytime I think about EDSLs.
>
> Let's assume that we have a complexity namespace in which we define
> symbols such as O, log, n, k, etc... to make a complexity EDSL.
> The symbols are all short and might have another meaning outside of the
> complexity namespace, so a using namespace complexity
> is out of the question when one wants to create a complexity expression,
> but prepending the namespace name before every element hinders
> readbility. One idea would be to have namespaced expressions of the
> following form;
>
> auto comp = complexity::{ O(n * log(n)) };
>
> In the expression above, the symbols O, log and n would be looked up into
> the complexity namespace first as if it was equivalent to the
> following expression:
>
> auto comp = [] {
>     using namespace complexity;
>     return O(n * log(n));
> }
>
> I don't think such a feature has much value outside of this kind of EDSL
> though, but it would allow to easily form an expression with elements
> of a namespace that is not needed later without hindering readability. The
> current simple solution would be to wrap the lambda into a macro,
> which isn't really sexy.
>
> Any additional thoughts?
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/95ee9c1f-abaa-45ae-810d-5a17318dfad9%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/95ee9c1f-abaa-45ae-810d-5a17318dfad9%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

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

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

<div dir=3D"ltr">Assuming &#39;n&#39; is a special variable with a special =
type, ADL already does what you need.</div><div class=3D"gmail_extra"><br><=
div class=3D"gmail_quote">On 29 April 2016 at 14:55, Morwenn <span dir=3D"l=
tr">&lt;<a href=3D"mailto:morwenn29@gmail.com" target=3D"_blank">morwenn29@=
gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr">A random idea that pops in my head everytime I think about EDSLs.<=
br><br>Let&#39;s assume that we have a <span style=3D"font-family:courier n=
ew,monospace">complexity</span> namespace in which we define symbols such a=
s <span style=3D"font-family:courier new,monospace">O</span>, <span style=
=3D"font-family:courier new,monospace">log</span>, <span style=3D"font-fami=
ly:courier new,monospace">n</span>, <span style=3D"font-family:courier new,=
monospace">k</span>, etc... to make a complexity EDSL.<br>The symbols are a=
ll short and might have another meaning outside of the <span style=3D"font-=
family:courier new,monospace">complexity</span> namespace, so a <span style=
=3D"font-family:courier new,monospace">using namespace complexity</span><br=
>is out of the question when one wants to create a complexity expression, b=
ut prepending the namespace name before every element hinders<br>readbility=
.. One idea would be to have namespaced expressions of the following form;<b=
r><br><div style=3D"margin-left:40px"><span style=3D"font-family:courier ne=
w,monospace">auto comp =3D complexity::{ O(n * log(n)) };<br></span></div><=
br>In the expression above, the symbols <span style=3D"font-family:courier =
new,monospace">O</span>, <span style=3D"font-family:courier new,monospace">=
log</span> and <span style=3D"font-family:courier new,monospace">n</span> w=
ould be looked up into the <span style=3D"font-family:courier new,monospace=
">complexity</span> namespace first as if it was equivalent to the<br>follo=
wing expression:<br><br><div style=3D"margin-left:40px"><span style=3D"font=
-family:courier new,monospace">auto comp =3D [] {<br>=C2=A0=C2=A0=C2=A0 usi=
ng namespace complexity;<br>=C2=A0=C2=A0=C2=A0 return O(n * log(n));<br>}<b=
r></span></div><br>I don&#39;t think such a feature has much value outside =
of this kind of EDSL though, but it would allow to easily form an expressio=
n with elements<br>of a namespace that is not needed later without hinderin=
g readability. The current simple solution would be to wrap the lambda into=
 a macro,<br>which isn&#39;t really sexy.<br><br>Any additional thoughts?<s=
pan class=3D"HOEnZb"><font color=3D"#888888"><br><br></font></span></div><s=
pan class=3D"HOEnZb"><font color=3D"#888888">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/95ee9c1f-abaa-45ae-810d-5a17318dfad9%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/95ee9c1f-abaa-=
45ae-810d-5a17318dfad9%40isocpp.org</a>.<br>
</font></span></blockquote></div><br></div>

<p></p>

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

--001a113fc2e8fe252a0531a62046--

.

------=_Part_80_83434053.1461972314769
Content-Type: multipart/alternative;
 boundary="----=_Part_81_249741422.1461972314769"

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

On Friday, April 29, 2016 at 2:14:33 PM UTC-7, Mathias Gaunard wrote:
>
> Assuming 'n' is a special variable with a special type, ADL already does=
=20
> what you need.
>

Unless I'm mistaken =E2=80=94 ADL will cause 'log' and 'O' to get looked up=
 in=20
namespace 'complexity' given that 'n' is 'complexity::n'; but it won't help=
=20
with the initial lookup of 'n', unless you drop a 'using complexity::n;'=20
directive somewhere in the current scope.


On 29 April 2016 at 14:55, Morwenn <morw...@gmail.com <javascript:>> wrote:
>
>> One idea would be to have namespaced expressions of the following form;
>>
>> auto comp =3D complexity::{ O(n * log(n)) };
>>
>
I like your syntax but with round parentheses instead of curly braces:

    auto comp =3D complexity::( O(n * log(n)) );

because this has the neat property that

    (foo::bar::n)  // and
    foo::(bar::n)  // and
    foo::bar::(n)

would have the same semantics.

Any solution of this type would *also* be a solution to the ongoing problem=
=20
of being unable to use UDLs (user-defined literals) in expressions at file=
=20
scope, which is awesome!

    constexpr auto FOO_DURATION =3D 3s;  // doesn't work because we don't=
=20
want to drop a "using namespace std::chrono_literals" at file scope
    constexpr auto FOO_DURATION =3D std::chrono_literals::( 3s );  // would=
=20
work fine

My only minor concern is that this seems like Yet Another place (just like=
=20
sizeof...() and fold-expressions) where the grammar would be adding a=20
basically redundant set of parentheses just to avoid the semblance of=20
grammatical ambiguity in obscure corner cases. Would it be a bad idea to=20
also try to allow constructs such as

    std::chrono_literals::3s
    std::chrono_literals::[]() { return utcnow() + 3s; }

?

Note that under this system, ::( *expr* ) means "do the same thing as (=20
*expr* ), but prefer to look up *expr*'s identifiers in the global=20
namespace."

I believe there wouldn't be any grammatical problems w.r.t. digraphs.

=E2=80=93Arthur

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/a8b3c4c1-ddc8-4410-9b2e-ef3ccef06c2f%40isocpp.or=
g.

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

<div dir=3D"ltr">On Friday, April 29, 2016 at 2:14:33 PM UTC-7, Mathias Gau=
nard 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">As=
suming &#39;n&#39; is a special variable with a special type, ADL already d=
oes what you need.</div></blockquote><div><br></div><div>Unless I&#39;m mis=
taken =E2=80=94 ADL will cause &#39;log&#39; and &#39;O&#39; to get looked =
up in namespace &#39;complexity&#39; given that &#39;n&#39; is &#39;complex=
ity::n&#39;; but it won&#39;t help with the initial lookup of &#39;n&#39;, =
unless you drop a &#39;using complexity::n;&#39; directive somewhere in the=
 current scope.</div><div><br></div><div><br></div><blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;"><div>On 29 April 2016 at 14:55, Morwenn <span dir=3D"l=
tr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
xFMQO_quBAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">morw...@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_quote"><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr">One idea would be to have nam=
espaced expressions of the following form;<br><br><div style=3D"margin-left=
:40px"><span style=3D"font-family:courier new,monospace">auto comp =3D comp=
lexity::{ O(n * log(n)) };<br></span></div></div></blockquote></div></div><=
/blockquote><div><br></div><div>I like your syntax but with round parenthes=
es instead of curly braces:</div><div><br></div><div class=3D"prettyprint" =
style=3D"background-color: rgb(250, 250, 250); border: 1px solid rgb(187, 1=
87, 187); word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D=
"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">=
=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">auto</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> c=
omp </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> complexity</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">::(</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> O</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">n </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">*</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> log</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">n</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
))</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code><=
/div><div><br></div><div>because this has the neat property that</div><div>=
<br></div><div class=3D"prettyprint" style=3D"background-color: rgb(250, 25=
0, 250); border: 1px solid rgb(187, 187, 187); word-wrap: break-word;"><cod=
e class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color:=
 #000;" class=3D"styled-by-prettify">=C2=A0 =C2=A0 </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">foo</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">bar</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">n</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> =C2=A0</span><s=
pan style=3D"color: #800;" class=3D"styled-by-prettify">// and</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 foo</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">::(</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">bar</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">n</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> =C2=A0</span><span style=3D"color: #800;" class=3D=
"styled-by-prettify">// and</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br>=C2=A0 =C2=A0 foo</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">bar</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">::(</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">n</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</=
span></div></code></div><div><br>would have the same semantics.<br></div><d=
iv><br></div><div>Any solution of this type would <i><b>also</b></i> be a s=
olution to the ongoing problem of being unable to use UDLs (user-defined li=
terals) in expressions at file scope, which is awesome!</div><div><br></div=
><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); =
border: 1px solid rgb(187, 187, 187); word-wrap: break-word;"><code class=
=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000;"=
 class=3D"styled-by-prettify">=C2=A0 =C2=A0 </span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">constexpr</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> FOO_DURATION </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-pr=
ettify">3s</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =C2=A0</=
span><span style=3D"color: #800;" class=3D"styled-by-prettify">// doesn&#39=
;t work because we don&#39;t want to drop a &quot;using namespace std::chro=
no_literals&quot; at file scope</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">constexpr</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> FOO_DURATION </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> std</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">chro=
no_literals</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>::(</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #066;" class=3D"styled-by-prettify">3s</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> =C2=A0</span><span style=3D"color: #800=
;" class=3D"styled-by-prettify">// would work fine</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br></span></div></code></div><div>=
<br>My only minor concern is that this seems like Yet Another place (just l=
ike sizeof...() and fold-expressions) where the grammar would be adding a b=
asically redundant set of parentheses just to avoid the semblance of gramma=
tical ambiguity in obscure corner cases. Would it be a bad idea to also try=
 to allow constructs such as</div><div><br></div><div class=3D"prettyprint"=
 style=3D"background-color: rgb(250, 250, 250); border: 1px solid rgb(187, =
187, 187); word-wrap: break-word;"><code class=3D"prettyprint"><div class=
=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">=C2=A0 =C2=A0 std</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">chrono_literals</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">::</span><span style=3D"color: #066;" class=3D"styled-by-prettify">3=
s</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=
=A0 =C2=A0 std</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">chro=
no_literals</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>::[]()</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">return</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> utcnow</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">()</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">+</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-pret=
tify">3s</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code></di=
v><div><br></div><div>?</div><div><br></div><div>Note that under this syste=
m,=C2=A0<font face=3D"courier new, monospace">::( <i>expr</i> )</font> mean=
s &quot;do the same thing as <font face=3D"courier new, monospace">( <i>exp=
r</i> )</font>, but prefer to look up <font face=3D"courier new, monospace"=
><i>expr</i></font>&#39;s identifiers in the global namespace.&quot;</div><=
div><br></div><div>I believe there wouldn&#39;t be any grammatical problems=
 w.r.t. digraphs.</div><div><br></div><div>=E2=80=93Arthur<br></div></div>

<p></p>

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

------=_Part_81_249741422.1461972314769--
------=_Part_80_83434053.1461972314769--

.

This is a multi-part message in MIME format.
--------------090401010803020306060904
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 29/04/2016 15:55, Morwenn a =C3=A9crit :
> A random idea that pops in my head everytime I think about EDSLs.
>
> Let's assume that we have a complexity namespace in which we define=20
> symbols such as O, log, n, k, etc... to make a complexity EDSL.
> The symbols are all short and might have another meaning outside of=20
> the complexity namespace, so a using namespace complexity
> is out of the question when one wants to create a complexity=20
> expression, but prepending the namespace name before every element hinder=
s
> readbility. One idea would be to have namespaced expressions of the=20
> following form;
>
> auto comp =3D complexity::{ O(n * log(n)) };
>
> In the expression above, the symbols O, log and n would be looked up=20
> into the complexity namespace first as if it was equivalent to the
> following expression:
>
> auto comp =3D [] {
>     using namespace complexity;
>     return O(n * log(n));
> }
>
> I don't think such a feature has much value outside of this kind of=20
> EDSL though, but it would allow to easily form an expression with element=
s
> of a namespace that is not needed later without hindering readability.=20
> The current simple solution would be to wrap the lambda into a macro,
> which isn't really sexy.
>
> Any additional thoughts?
I like the general idea.

I like also the idea of using a namespace as a function name, that=20
evaluates the expression as if we had using namespace ns.

auto comp =3D complexity( O(n * log(n)) );


I have another idea a little bit more general:  Add expressions that are=20
the composition of an statement and another expression.

We could use the ':' token to split the statement and the expression.

auto comp =3D using namespace complexity : O(n * log(n));

This is more verbose than your syntax, but it could be used in other=20
contexts e.g

f(using std::swap : swap(a,b));

expression :: ... | statement_expresion
statement_expresion ::=3D statement ':' expression


Vicente

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

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

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">Le 29/04/2016 15:55, Morwenn a =C3=A9cri=
t=C2=A0:<br>
    </div>
    <blockquote
      cite=3D"mid:95ee9c1f-abaa-45ae-810d-5a17318dfad9@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">A random idea that pops in my head everytime I
        think about EDSLs.<br>
        <br>
        Let's assume that we have a <span style=3D"font-family: courier
          new,monospace;">complexity</span> namespace in which we define
        symbols such as <span style=3D"font-family: courier
          new,monospace;">O</span>, <span style=3D"font-family: courier
          new,monospace;">log</span>, <span style=3D"font-family: courier
          new,monospace;">n</span>, <span style=3D"font-family: courier
          new,monospace;">k</span>, etc... to make a complexity EDSL.<br>
        The symbols are all short and might have another meaning outside
        of the <span style=3D"font-family: courier new,monospace;">complexi=
ty</span>
        namespace, so a <span style=3D"font-family: courier
          new,monospace;">using namespace complexity</span><br>
        is out of the question when one wants to create a complexity
        expression, but prepending the namespace name before every
        element hinders<br>
        readbility. One idea would be to have namespaced expressions of
        the following form;<br>
        <br>
        <div style=3D"margin-left: 40px;"><span style=3D"font-family:
            courier new,monospace;">auto comp =3D complexity::{ O(n *
            log(n)) };<br>
          </span></div>
        <br>
        In the expression above, the symbols <span style=3D"font-family:
          courier new,monospace;">O</span>, <span style=3D"font-family:
          courier new,monospace;">log</span> and <span
          style=3D"font-family: courier new,monospace;">n</span> would be
        looked up into the <span style=3D"font-family: courier
          new,monospace;">complexity</span> namespace first as if it was
        equivalent to the<br>
        following expression:<br>
        <br>
        <div style=3D"margin-left: 40px;"><span style=3D"font-family:
            courier new,monospace;">auto comp =3D [] {<br>
            =C2=A0=C2=A0=C2=A0 using namespace complexity;<br>
            =C2=A0=C2=A0=C2=A0 return O(n * log(n));<br>
            }<br>
          </span></div>
        <br>
        I don't think such a feature has much value outside of this kind
        of EDSL though, but it would allow to easily form an expression
        with elements<br>
        of a namespace that is not needed later without hindering
        readability. The current simple solution would be to wrap the
        lambda into a macro,<br>
        which isn't really sexy.<br>
        <br>
        Any additional thoughts?<br>
      </div>
    </blockquote>
    I like the general idea.<br>
    <br>
    I like also the idea of using a namespace as a function name, that
    evaluates the expression as if we had using namespace ns.<br>
    <br>
    <div style=3D"margin-left: 40px;"><span style=3D"font-family: courier
        new,monospace;">auto comp =3D complexity( O(n * log(n)) );<br>
      </span></div>
    <br>
    <br>
    I have another idea a little bit more general:=C2=A0 Add <font size=3D"=
+1">expressions
      that are the composition of an statement and another expression.<br>
      <br>
      We could use the ':' token to split the statement and the
      expression. <br>
      <br>
      auto comp =3D using namespace complexity : O(n * log(n));<br>
    </font><br>
    This is more verbose than your syntax, but it could be used in other
    contexts e.g<br>
    <br>
    f(using std::swap : swap(a,b));<br>
    <br>
    expression :: ... | statement_expresion<br>
    statement_expresion ::=3D statement ':' expression<br>
    <br>
    <br>
    Vicente<br>
  </body>
</html>

<p></p>

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

--------------090401010803020306060904--

.

On Sun, May 01, 2016 at 08:00:09PM +0200, Vicente J. Botet Escriba wrote:
> Le 29/04/2016 15:55, Morwenn a =C3=A9crit :
> > A random idea that pops in my head everytime I think about EDSLs.
> >=20
> > Let's assume that we have a complexity namespace in which we define
> > symbols such as O, log, n, k, etc... to make a complexity EDSL.
> > The symbols are all short and might have another meaning outside of the
> > complexity namespace, so a using namespace complexity
> > is out of the question when one wants to create a complexity expression=
,
> > but prepending the namespace name before every element hinders
> > readbility. One idea would be to have namespaced expressions of the
> > following form;
> >=20
> > auto comp =3D complexity::{ O(n * log(n)) };
> >=20
> > In the expression above, the symbols O, log and n would be looked up
> > into the complexity namespace first as if it was equivalent to the
> > following expression:
> >=20
> > auto comp =3D [] {
> >     using namespace complexity;
> >     return O(n * log(n));
> > }
> >=20
> > I don't think such a feature has much value outside of this kind of EDS=
L
> > though, but it would allow to easily form an expression with elements
> > of a namespace that is not needed later without hindering readability.
> > The current simple solution would be to wrap the lambda into a macro,
> > which isn't really sexy.
> >=20
> > Any additional thoughts?
> I like the general idea.
>=20
> I like also the idea of using a namespace as a function name, that evalua=
tes
> the expression as if we had using namespace ns.
>=20
> auto comp =3D complexity( O(n * log(n)) );

I do dislike that idea strongly.
Consider:

namespace foo {
        int bar() { return 0; }
}

namespace fie {
        int bar() { return 1; }
        int foo(int i) { return i; }
        int gaz() { return foo(bar()); }
}

What would this result in using your syntax?
What happens if fie::foo is removed or fails a SFINAE-check?

> I have another idea a little bit more general:  Add expressions that are =
the
> composition of an statement and another expression.

Why not go all the way and add GCC-style statement expressions?

> We could use the ':' token to split the statement and the expression.
>=20
> auto comp =3D using namespace complexity : O(n * log(n));
>=20
> This is more verbose than your syntax, but it could be used in other
> contexts e.g
>=20
> f(using std::swap : swap(a,b));
>=20
> expression :: ... | statement_expresion
> statement_expresion ::=3D statement ':' expression

Like this:

for (int i : int j : aVectorOfInts) { }

I think it could be useful in an obfuscated C++ contest.

/MF

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

.

Le 01/05/2016 20:36, Magnus Fromreide a =C3=A9crit :
> On Sun, May 01, 2016 at 08:00:09PM +0200, Vicente J. Botet Escriba wrote:
>> Le 29/04/2016 15:55, Morwenn a =C3=A9crit :
>>> A random idea that pops in my head everytime I think about EDSLs.
>>>
>>> Let's assume that we have a complexity namespace in which we define
>>> symbols such as O, log, n, k, etc... to make a complexity EDSL.
>>> The symbols are all short and might have another meaning outside of the
>>> complexity namespace, so a using namespace complexity
>>> is out of the question when one wants to create a complexity expression=
,
>>> but prepending the namespace name before every element hinders
>>> readbility. One idea would be to have namespaced expressions of the
>>> following form;
>>>
>>> auto comp =3D complexity::{ O(n * log(n)) };
>>>
>>> In the expression above, the symbols O, log and n would be looked up
>>> into the complexity namespace first as if it was equivalent to the
>>> following expression:
>>>
>>> auto comp =3D [] {
>>>      using namespace complexity;
>>>      return O(n * log(n));
>>> }
>>>
>>> I don't think such a feature has much value outside of this kind of EDS=
L
>>> though, but it would allow to easily form an expression with elements
>>> of a namespace that is not needed later without hindering readability.
>>> The current simple solution would be to wrap the lambda into a macro,
>>> which isn't really sexy.
>>>
>>> Any additional thoughts?
>> I like the general idea.
>>
>> I like also the idea of using a namespace as a function name, that evalu=
ates
>> the expression as if we had using namespace ns.
>>
>> auto comp =3D complexity( O(n * log(n)) );
> I do dislike that idea strongly.
My intent wasn't that you like it ;-)
> Consider:
>
> namespace foo {
>          int bar() { return 0; }
> }
>
> namespace fie {
>          int bar() { return 1; }
>          int foo(int i) { return i; }
>          int gaz() { return foo(bar()); }
> }
>
> What would this result in using your syntax?
> What happens if fie::foo is removed or fails a SFINAE-check?
Well, as it was your case, it was just an idea. What would you expect?
>
>> I have another idea a little bit more general:  Add expressions that are=
 the
>> composition of an statement and another expression.
> Why not go all the way and add GCC-style statement expressions?
yes, why not go in this direction?
>> We could use the ':' token to split the statement and the expression.
>>
>> auto comp =3D using namespace complexity : O(n * log(n));
>>
>> This is more verbose than your syntax, but it could be used in other
>> contexts e.g
>>
>> f(using std::swap : swap(a,b));
>>
>> expression :: ... | statement_expresion
>> statement_expresion ::=3D statement ':' expression
> Like this:
>
> for (int i : int j : aVectorOfInts) { }
>
> I think it could be useful in an obfuscated C++ contest.
>
>
Sure.

Vicente

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

.

On Sun, May 01, 2016 at 09:42:06PM +0200, Vicente J. Botet Escriba wrote:
> Le 01/05/2016 20:36, Magnus Fromreide a =C3=A9crit :
> > On Sun, May 01, 2016 at 08:00:09PM +0200, Vicente J. Botet Escriba wrot=
e:
> > > Le 29/04/2016 15:55, Morwenn a =C3=A9crit :
> > > > A random idea that pops in my head everytime I think about EDSLs.
> > > >=20
> > > > Let's assume that we have a complexity namespace in which we define
> > > > symbols such as O, log, n, k, etc... to make a complexity EDSL.
> > > > The symbols are all short and might have another meaning outside of=
 the
> > > > complexity namespace, so a using namespace complexity
> > > > is out of the question when one wants to create a complexity expres=
sion,
> > > > but prepending the namespace name before every element hinders
> > > > readbility. One idea would be to have namespaced expressions of the
> > > > following form;
> > > >=20
> > > > auto comp =3D complexity::{ O(n * log(n)) };
> > > >=20
> > > > In the expression above, the symbols O, log and n would be looked u=
p
> > > > into the complexity namespace first as if it was equivalent to the
> > > > following expression:
> > > >=20
> > > > auto comp =3D [] {
> > > >      using namespace complexity;
> > > >      return O(n * log(n));
> > > > }
> > > >=20
> > > > I don't think such a feature has much value outside of this kind of=
 EDSL
> > > > though, but it would allow to easily form an expression with elemen=
ts
> > > > of a namespace that is not needed later without hindering readabili=
ty.
> > > > The current simple solution would be to wrap the lambda into a macr=
o,
> > > > which isn't really sexy.
> > > >=20
> > > > Any additional thoughts?
> > > I like the general idea.
> > >=20
> > > I like also the idea of using a namespace as a function name, that ev=
aluates
> > > the expression as if we had using namespace ns.
> > >=20
> > > auto comp =3D complexity( O(n * log(n)) );
> > I do dislike that idea strongly.
> My intent wasn't that you like it ;-)

:-) I do kind of expect that your priority is for you to like it, this was
just to show that there is an opposing opinion.

I should probably clarify that it is the idea of using the namespace name a=
s
a function name I am opposed to, not the proposal as a whole.

> > Consider:
> >=20
> > namespace foo {
> >          int bar() { return 0; }
> > }
> >=20
> > namespace fie {
> >          int bar() { return 1; }
> >          int foo(int i) { return i; }
> >          int gaz() { return foo(bar()); }
> > }
> >=20
> > What would this result in using your syntax?
> > What happens if fie::foo is removed or fails a SFINAE-check?
> Well, as it was your case, it was just an idea. What would you expect?

That is the problem - I would expect the code as written to call fie::bar a=
nd
pass the result of it to fie::foo since this is what that code does today, =
and
breaking old code is a sure way to make a proposal a non-starter.

Now, if fie::foo did exist but wasn't viable then I really would hope to ge=
t
an ambiguity error in order to avoid bad surprises, but then that would
reduce the utility of the new feature and that is also bad.

If, on the other hand fie::foo is removed then I would expect the new synta=
x
to result in foo::bar beeing called since that is the whole point of the
new feature.

Now, express this in standard language and make sure I didn't miss any case=
 and
it looks like a big feature with small utility and that is why I dislike it=
..

> > > I have another idea a little bit more general:  Add expressions that =
are the
> > > composition of an statement and another expression.
> > Why not go all the way and add GCC-style statement expressions?
> yes, why not go in this direction?

I fear it might end up beeing a big can of worms even if I do think they mi=
ght
be useful and they do enable some things that are hard to achive today, at
least if you wish to avoid exceptions.

int fie() {
 const Foo aFoo =3D ({
  Foo f;
  if (!f.setup())
   return -1; // Returns from fie()
  f;
 });
 /* Do more stuff */
}

/MF

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

.

Le 03/05/2016 =C3=A0 08:57, Magnus Fromreide a =C3=A9crit :
> On Sun, May 01, 2016 at 09:42:06PM +0200, Vicente J. Botet Escriba wrote:
>> Le 01/05/2016 20:36, Magnus Fromreide a =C3=A9crit :
>>> On Sun, May 01, 2016 at 08:00:09PM +0200, Vicente J. Botet Escriba wrot=
e:
>>>> Le 29/04/2016 15:55, Morwenn a =C3=A9crit :
>>>>> A random idea that pops in my head everytime I think about EDSLs.
>>>>>
>>>>> Let's assume that we have a complexity namespace in which we define
>>>>> symbols such as O, log, n, k, etc... to make a complexity EDSL.
>>>>> The symbols are all short and might have another meaning outside of t=
he
>>>>> complexity namespace, so a using namespace complexity
>>>>> is out of the question when one wants to create a complexity expressi=
on,
>>>>> but prepending the namespace name before every element hinders
>>>>> readbility. One idea would be to have namespaced expressions of the
>>>>> following form;
>>>>>
>>>>> auto comp =3D complexity::{ O(n * log(n)) };
>>>>>
>>>>> In the expression above, the symbols O, log and n would be looked up
>>>>> into the complexity namespace first as if it was equivalent to the
>>>>> following expression:
>>>>>
>>>>> auto comp =3D [] {
>>>>>       using namespace complexity;
>>>>>       return O(n * log(n));
>>>>> }
>>>>>
>>>>> I don't think such a feature has much value outside of this kind of E=
DSL
>>>>> though, but it would allow to easily form an expression with elements
>>>>> of a namespace that is not needed later without hindering readability=
..
>>>>> The current simple solution would be to wrap the lambda into a macro,
>>>>> which isn't really sexy.
>>>>>
>>>>> Any additional thoughts?
>>>> I like the general idea.
>>>>
>>>> I like also the idea of using a namespace as a function name, that eva=
luates
>>>> the expression as if we had using namespace ns.
>>>>
>>>> auto comp =3D complexity( O(n * log(n)) );
>>> I do dislike that idea strongly.
>> My intent wasn't that you like it ;-)
> :-) I do kind of expect that your priority is for you to like it, this wa=
s
> just to show that there is an opposing opinion.
>
> I should probably clarify that it is the idea of using the namespace name=
 as
> a function name I am opposed to, not the proposal as a whole.
I understood it completely.


>>> Consider:
>>>
>>> namespace foo {
>>>           int bar() { return 0; }
>>> }
>>>
>>> namespace fie {
>>>           int bar() { return 1; }
>>>           int foo(int i) { return i; }
>>>           int gaz() { return foo(bar()); }
>>> }
>>>
>>> What would this result in using your syntax?
>>> What happens if fie::foo is removed or fails a SFINAE-check?
>> Well, as it was your case, it was just an idea. What would you expect?
> That is the problem - I would expect the code as written to call fie::bar=
 and
> pass the result of it to fie::foo since this is what that code does today=
, and
> breaking old code is a sure way to make a proposal a non-starter.
Here we agree.
>
> Now, if fie::foo did exist but wasn't viable then I really would hope to =
get
> an ambiguity error in order to avoid bad surprises, but then that would
> reduce the utility of the new feature and that is also bad.
We disagree here. I would prefer the namespace expression behavior in=20
this case.

>
> If, on the other hand fie::foo is removed then I would expect the new syn=
tax
> to result in foo::bar beeing called since that is the whole point of the
> new feature.
Agree.

Do you believe that you will have a lot of real cases when a namespace=20
and a function have the same name?

> Now, express this in standard language and make sure I didn't miss any ca=
se and
> it looks like a big feature with small utility and that is why I dislike =
it.
I don't believe it is so hard to add this overload. I agree with you=20
that the wording with a specific namespace expression would surely be=20
easier, but you need to add a additional syntax.

Anyway, I don't believe that the function call syntax would be=20
appreciated a lot, so I believe we can finish this part of the thread.
>
>>>> I have another idea a little bit more general:  Add expressions that a=
re the
>>>> composition of an statement and another expression.
>>> Why not go all the way and add GCC-style statement expressions?
>> yes, why not go in this direction?
> I fear it might end up beeing a big can of worms
Why?

After some more thoughts, I believe that adding a specific syntax for=20
the namespaced-expressions when we could have one for=20
statement-expressions is too specific feature.
> even if I do think they might
> be useful and they do enable some things that are hard to achive today, a=
t
> least if you wish to avoid exceptions.
>
> int fie() {
>  const Foo aFoo =3D ({
>   Foo f;
>   if (!f.setup())
>    return -1; // Returns from fie()
>   f;
>  });
>  /* Do more stuff */
> }
How would the previous code written without statement-expressions be=20
different? What is your point?

Vicente

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/ad8770d9-5d53-8ec9-5e91-0b927adabf93%40wanadoo.f=
r.

.

On Sun, May 08, 2016 at 03:46:49PM +0200, Vicente J. Botet Escriba wrote:
> Le 03/05/2016 =C3=A0 08:57, Magnus Fromreide a =C3=A9crit :
> > On Sun, May 01, 2016 at 09:42:06PM +0200, Vicente J. Botet Escriba wrot=
e:
> > > Le 01/05/2016 20:36, Magnus Fromreide a =C3=A9crit :
> > > > On Sun, May 01, 2016 at 08:00:09PM +0200, Vicente J. Botet Escriba =
wrote:
> > > > > Le 29/04/2016 15:55, Morwenn a =C3=A9crit :
> > > > > > A random idea that pops in my head everytime I think about EDSL=
s.
> > > > > >=20
> > > > > > Let's assume that we have a complexity namespace in which we de=
fine
> > > > > > symbols such as O, log, n, k, etc... to make a complexity EDSL.
> > > > > > The symbols are all short and might have another meaning outsid=
e of the
> > > > > > complexity namespace, so a using namespace complexity
> > > > > > is out of the question when one wants to create a complexity ex=
pression,
> > > > > > but prepending the namespace name before every element hinders
> > > > > > readbility. One idea would be to have namespaced expressions of=
 the
> > > > > > following form;
> > > > > >=20
> > > > > > auto comp =3D complexity::{ O(n * log(n)) };
> > > > > >=20
> > > > > > In the expression above, the symbols O, log and n would be look=
ed up
> > > > > > into the complexity namespace first as if it was equivalent to =
the
> > > > > > following expression:
> > > > > >=20
> > > > > > auto comp =3D [] {
> > > > > >       using namespace complexity;
> > > > > >       return O(n * log(n));
> > > > > > }
> > > > > >=20
> > > > > > I don't think such a feature has much value outside of this kin=
d of EDSL
> > > > > > though, but it would allow to easily form an expression with el=
ements
> > > > > > of a namespace that is not needed later without hindering reada=
bility.
> > > > > > The current simple solution would be to wrap the lambda into a =
macro,
> > > > > > which isn't really sexy.
> > > > > >=20
> > > > > > Any additional thoughts?
> > > > > I like the general idea.
> > > > >=20
> > > > > I like also the idea of using a namespace as a function name, tha=
t evaluates
> > > > > the expression as if we had using namespace ns.
> > > > >=20
> > > > > auto comp =3D complexity( O(n * log(n)) );
> > > > I do dislike that idea strongly.
> > > My intent wasn't that you like it ;-)
> > :-) I do kind of expect that your priority is for you to like it, this =
was
> > just to show that there is an opposing opinion.
> >=20
> > I should probably clarify that it is the idea of using the namespace na=
me as
> > a function name I am opposed to, not the proposal as a whole.
> I understood it completely.
>=20
>=20
> > > > Consider:
> > > >=20
> > > > namespace foo {
> > > >           int bar() { return 0; }
> > > > }
> > > >=20
> > > > namespace fie {
> > > >           int bar() { return 1; }
> > > >           int foo(int i) { return i; }
> > > >           int gaz() { return foo(bar()); }
> > > > }
> > > >=20
> > > > What would this result in using your syntax?
> > > > What happens if fie::foo is removed or fails a SFINAE-check?
> > > Well, as it was your case, it was just an idea. What would you expect=
?
> > That is the problem - I would expect the code as written to call fie::b=
ar and
> > pass the result of it to fie::foo since this is what that code does tod=
ay, and
> > breaking old code is a sure way to make a proposal a non-starter.
> Here we agree.
> >=20
> > Now, if fie::foo did exist but wasn't viable then I really would hope t=
o get
> > an ambiguity error in order to avoid bad surprises, but then that would
> > reduce the utility of the new feature and that is also bad.
> We disagree here. I would prefer the namespace expression behavior in thi=
s
> case.
>=20
> >=20
> > If, on the other hand fie::foo is removed then I would expect the new s=
yntax
> > to result in foo::bar beeing called since that is the whole point of th=
e
> > new feature.
> Agree.
>=20
> Do you believe that you will have a lot of real cases when a namespace an=
d a
> function have the same name?

No, but I would hate mixing up the namespace-name and function-name namespa=
ces.

> > Now, express this in standard language and make sure I didn't miss any =
case and
> > it looks like a big feature with small utility and that is why I dislik=
e it.
> I don't believe it is so hard to add this overload. I agree with you that
> the wording with a specific namespace expression would surely be easier, =
but
> you need to add a additional syntax.
>=20
> Anyway, I don't believe that the function call syntax would be appreciate=
d a
> lot, so I believe we can finish this part of the thread.

Agreed.

> >=20
> > > > > I have another idea a little bit more general:  Add expressions t=
hat are the
> > > > > composition of an statement and another expression.
> > > > Why not go all the way and add GCC-style statement expressions?
> > > yes, why not go in this direction?
> > I fear it might end up beeing a big can of worms
> Why?
>=20
> After some more thoughts, I believe that adding a specific syntax for the
> namespaced-expressions when we could have one for statement-expressions i=
s
> too specific feature.
> > even if I do think they might
> > be useful and they do enable some things that are hard to achive today,=
 at
> > least if you wish to avoid exceptions.
> >=20
> > int fie() {
> >  const Foo aFoo =3D ({
> >   Foo f;
> >   if (!f.setup())
> >    return -1; // Returns from fie()
> >   f;
> >  });
> >  /* Do more stuff */
> > }
> How would the previous code written without statement-expressions be
> different? What is your point?

I have though some more and came to the conclusion that I didn't have a
point here.

/MF

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

.