Topic: Can we move consteval out of declarations into an


Author: mihailnajdenov@gmail.com
Date: Thu, 18 Oct 2018 09:44:51 -0700 (PDT)
Raw View
------=_Part_3313_1382243807.1539881091496
Content-Type: multipart/alternative;
 boundary="----=_Part_3314_532064226.1539881091496"

------=_Part_3314_532064226.1539881091496
Content-Type: text/plain; charset="UTF-8"

To the point:

From this:

namespace std::meta {
  consteval auto byte_offset_of(info entity)->std::size_t {...};
  consteval auto bit_offset_of(info entity)->std::size_t {...};
  consteval auto byte_size_of(info entity)->std::size_t {...};
  consteval auto bit_size_of(info entity)->std::size_t {...};

  // ... literally hundreds more lines!
}

into this:

namespace std::meta {
consteval:
  auto byte_offset_of(info entity)->std::size_t {...};
  auto bit_offset_of(info entity)->std::size_t {...};
  auto byte_size_of(info entity)->std::size_t {...};
  auto bit_size_of(info entity)->std::size_t {...};
}

Considering, namespaces can be reopened, we don't even need a keyword to
"turn this off", we could just close and reopen the namespace.

The point is, the reflection API will be *exclusively *consteval, which
means hundreds upon hundreds of redundant keywords.

Thoughts?
I thought of alternatives, but none is better, mainly because they
introduce problems of their own, where this is just a syntactical shortcut.


P.S. I think we can also make the keyword contextual this way, no?

--
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/cf53ce50-5c2e-4ad8-a387-872ee5c334c6%40isocpp.org.

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

<div dir=3D"ltr">To the point:<div><br></div><div>From this:=C2=A0</div><di=
v><br></div><div><font face=3D"courier new, monospace">namespace std::meta =
{=C2=A0</font></div><div><font face=3D"courier new, monospace">=C2=A0 const=
eval auto byte_offset_of(info entity)-&gt;std::size_t {...};=C2=A0</font></=
div><div><font face=3D"courier new, monospace">=C2=A0=C2=A0</font><span sty=
le=3D"font-family: &quot;courier new&quot;, monospace;">consteval=C2=A0</sp=
an><font face=3D"courier new, monospace">auto bit_offset_of(info entity)-&g=
t;std::size_t {...};=C2=A0</font></div><div><font face=3D"courier new, mono=
space">=C2=A0=C2=A0</font><span style=3D"font-family: &quot;courier new&quo=
t;, monospace;">consteval=C2=A0</span><font face=3D"courier new, monospace"=
>auto byte_size_of(info entity)-&gt;std::size_t {...};=C2=A0</font></div><d=
iv><font face=3D"courier new, monospace">=C2=A0=C2=A0</font><span style=3D"=
font-family: &quot;courier new&quot;, monospace;">consteval</span><font fac=
e=3D"courier new, monospace">=C2=A0auto bit_size_of(info entity)-&gt;std::s=
ize_t {...};=C2=A0</font></div><div><font face=3D"courier new, monospace"><=
br></font></div><div><font face=3D"courier new, monospace">=C2=A0 // ... li=
terally hundreds more lines!=C2=A0</font></div><div><font face=3D"courier n=
ew, monospace">}</font><br></div><div><font face=3D"courier new, monospace"=
><br></font></div><div><font face=3D"arial, sans-serif">into this:</font></=
div><div><font face=3D"arial, sans-serif"><br></font></div><div><div><font =
face=3D"courier new, monospace">namespace std::meta {=C2=A0</font></div><di=
v><span style=3D"font-family: &quot;courier new&quot;, monospace;">consteva=
l:</span><font face=3D"courier new, monospace">=C2=A0</font></div><div><fon=
t face=3D"courier new, monospace">=C2=A0 auto byte_offset_of(info entity)-&=
gt;std::size_t {...};=C2=A0</font></div><div><font face=3D"courier new, mon=
ospace">=C2=A0 auto bit_offset_of(info entity)-&gt;std::size_t {...};=C2=A0=
</font></div><div><font face=3D"courier new, monospace">=C2=A0 auto byte_si=
ze_of(info entity)-&gt;std::size_t {...};=C2=A0</font></div><div><font face=
=3D"courier new, monospace">=C2=A0 auto bit_size_of(info entity)-&gt;std::s=
ize_t {...};=C2=A0</font></div><div><font face=3D"courier new, monospace">}=
</font></div></div><div><font face=3D"courier new, monospace"><br></font></=
div><div><font face=3D"arial, sans-serif">Considering, namespaces can be re=
opened, we don&#39;t even need a keyword to &quot;turn this off&quot;, we c=
ould just close and reopen the namespace.</font></div><div><font face=3D"ar=
ial, sans-serif"><br></font></div><div><font face=3D"arial, sans-serif">The=
 point is, the reflection API will be <i>exclusively=C2=A0</i></font><font =
face=3D"courier new, monospace">consteval, </font><font face=3D"arial, sans=
-serif">which means hundreds=C2=A0upon hundreds of redundant keywords.</fon=
t></div><div><font face=3D"arial, sans-serif"><br></font></div><div><font f=
ace=3D"arial, sans-serif">Thoughts?=C2=A0</font></div><div><font face=3D"ar=
ial, sans-serif">I thought of alternatives, but none is better, mainly beca=
use they introduce problems of their own, where this is just a syntactical =
shortcut.</font></div><div><br></div><div><font face=3D"arial, sans-serif">=
<br></font></div><div><font face=3D"arial, sans-serif">P.S. I think we can =
also make the keyword contextual this way, no?</font></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/cf53ce50-5c2e-4ad8-a387-872ee5c334c6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/cf53ce50-5c2e-4ad8-a387-872ee5c334c6=
%40isocpp.org</a>.<br />

------=_Part_3314_532064226.1539881091496--

------=_Part_3313_1382243807.1539881091496--

.


Author: Jakob Riedle <jakob.riedle@gmail.com>
Date: Thu, 18 Oct 2018 13:27:09 -0700 (PDT)
Raw View
------=_Part_3331_270734603.1539894429262
Content-Type: multipart/alternative;
 boundary="----=_Part_3332_937573524.1539894429262"

------=_Part_3332_937573524.1539894429262
Content-Type: text/plain; charset="UTF-8"



Am Donnerstag, 18. Oktober 2018 18:44:51 UTC+2 schrieb mihailn...@gmail.com:
>
> namespace std::meta {
>   consteval auto byte_offset_of(info entity)->std::size_t {...};
>   consteval auto bit_offset_of(info entity)->std::size_t {...};
>   consteval auto byte_size_of(info entity)->std::size_t {...};
>   consteval auto bit_size_of(info entity)->std::size_t {...};
>
>   // ... literally hundreds more lines!
> }
>
Do you mean
constexpr
?

Best Regards
Jakob

--
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/29c8c6b5-18f7-48ff-8d43-f0c0ca90c9fe%40isocpp.org.

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

<div dir=3D"ltr"><br><br>Am Donnerstag, 18. Oktober 2018 18:44:51 UTC+2 sch=
rieb mihailn...@gmail.com:<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><font face=3D"courier new, monospace">namespace std::meta=
 {=C2=A0</font></div><div><font face=3D"courier new, monospace">=C2=A0 cons=
teval auto byte_offset_of(info entity)-&gt;std::size_t {...};=C2=A0</font><=
/div><div><font face=3D"courier new, monospace">=C2=A0=C2=A0</font><span st=
yle=3D"font-family:&quot;courier new&quot;,monospace">consteval=C2=A0</span=
><font face=3D"courier new, monospace">auto bit_offset_of(info entity)-&gt;=
std::size_t {...};=C2=A0</font></div><div><font face=3D"courier new, monosp=
ace">=C2=A0=C2=A0</font><span style=3D"font-family:&quot;courier new&quot;,=
monospace">consteval=C2=A0</span><font face=3D"courier new, monospace">auto=
 byte_size_of(info entity)-&gt;std::size_t {...};=C2=A0</font></div><div><f=
ont face=3D"courier new, monospace">=C2=A0=C2=A0</font><span style=3D"font-=
family:&quot;courier new&quot;,monospace">consteval</span><font face=3D"cou=
rier new, monospace">=C2=A0auto bit_size_of(info entity)-&gt;std::size_t {.=
...};=C2=A0</font></div><div><font face=3D"courier new, monospace"><br></fon=
t></div><div><font face=3D"courier new, monospace">=C2=A0 // ... literally =
hundreds more lines!=C2=A0</font></div><div><font face=3D"courier new, mono=
space">}</font></div></div></blockquote><div>Do you mean=C2=A0<div class=3D=
"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-color: =
rgb(187, 187, 187); border-style: solid; border-width: 1px; overflow-wrap: =
break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">constexpr</span></div=
></code></div>?<br>=C2=A0</div><div>Best Regards</div><div>Jakob</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/29c8c6b5-18f7-48ff-8d43-f0c0ca90c9fe%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/29c8c6b5-18f7-48ff-8d43-f0c0ca90c9fe=
%40isocpp.org</a>.<br />

------=_Part_3332_937573524.1539894429262--

------=_Part_3331_270734603.1539894429262--

.


Author: pasa@lib.hu
Date: Thu, 18 Oct 2018 15:30:54 -0700 (PDT)
Raw View
------=_Part_3286_2101754663.1539901854852
Content-Type: multipart/alternative;
 boundary="----=_Part_3287_1735023717.1539901854852"

------=_Part_3287_1735023717.1539901854852
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



2018. okt=C3=B3ber 18., cs=C3=BCt=C3=B6rt=C3=B6k 22:27:09 UTC+2 id=C5=91pon=
tban Jakob Riedle a=20
k=C3=B6vetkez=C5=91t =C3=ADrta:
>
>
>
> Am Donnerstag, 18. Oktober 2018 18:44:51 UTC+2 schrieb=20
> mihailn...@gmail.com:
>>
>> namespace std::meta {=20
>>   consteval auto byte_offset_of(info entity)->std::size_t {...};=20
>>   consteval auto bit_offset_of(info entity)->std::size_t {...};=20
>>   consteval auto byte_size_of(info entity)->std::size_t {...};=20
>>   consteval auto bit_size_of(info entity)->std::size_t {...};=20
>>
>>   // ... literally hundreds more lines!=20
>> }
>>
> Do you mean=20
> constexpr
>
>
No, that is consteval for immediate functions, see p1073r2 =20
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1073r2.html>

As for the idea, it looks nice reading and writing-wise for the particular=
=20
case. But it breaks plenty of "ground rules" bigtime. If you consider the=
=20
massive battle over the terse template/concept syntax, where you could not=
=20
tell if a thing you see is function or template, only looking way back --=
=20
here the case is similar.=20

You see a sensible declaration, and it gets modified by text way before.=20
Likely hell for tools, let alone humans. This way of application might fly=
=20
for some attribute, but not for this.



--=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/2fd59c48-8023-49f0-a520-33170f9aea04%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>2018. okt=C3=B3ber 18., cs=C3=BCt=C3=B6rt=C3=B6k 2=
2:27:09 UTC+2 id=C5=91pontban Jakob Riedle a k=C3=B6vetkez=C5=91t =C3=ADrta=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><br>Am D=
onnerstag, 18. Oktober 2018 18:44:51 UTC+2 schrieb <a>mihailn...@gmail.com<=
/a>:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><font fac=
e=3D"courier new, monospace">namespace std::meta {=C2=A0</font></div><div><=
font face=3D"courier new, monospace">=C2=A0 consteval auto byte_offset_of(i=
nfo entity)-&gt;std::size_t {...};=C2=A0</font></div><div><font face=3D"cou=
rier new, monospace">=C2=A0=C2=A0</font><span style=3D"font-family:&quot;co=
urier new&quot;,monospace">consteval=C2=A0</span><font face=3D"courier new,=
 monospace">auto bit_offset_of(info entity)-&gt;std::size_t {...};=C2=A0</f=
ont></div><div><font face=3D"courier new, monospace">=C2=A0=C2=A0</font><sp=
an style=3D"font-family:&quot;courier new&quot;,monospace">consteval=C2=A0<=
/span><font face=3D"courier new, monospace">auto byte_size_of(info entity)-=
&gt;std::size_t {...};=C2=A0</font></div><div><font face=3D"courier new, mo=
nospace">=C2=A0=C2=A0</font><span style=3D"font-family:&quot;courier new&qu=
ot;,monospace">consteval</span><font face=3D"courier new, monospace">=C2=A0=
auto bit_size_of(info entity)-&gt;std::size_t {...};=C2=A0</font></div><div=
><font face=3D"courier new, monospace"><br></font></div><div><font face=3D"=
courier new, monospace">=C2=A0 // ... literally hundreds more lines!=C2=A0<=
/font></div><div><font face=3D"courier new, monospace">}</font></div></div>=
</blockquote><div>Do you mean=C2=A0<div style=3D"background-color:rgb(250,2=
50,250);border-color:rgb(187,187,187);border-style:solid;border-width:1px">=
<code><div><span style=3D"color:#008">constexpr</span></div></code></div></=
div><br></div></blockquote><div><br></div><div>No, that is consteval for im=
mediate functions, see <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/do=
cs/papers/2018/p1073r2.html">p1073r2=C2=A0 <br></a></div><div><br></div><di=
v>As for the idea, it looks nice reading and writing-wise for the particula=
r case. But it breaks plenty of &quot;ground rules&quot; bigtime. If you co=
nsider the massive battle over the terse template/concept syntax, where you=
 could not tell if a thing you see is function or template, only looking wa=
y back -- here the case is similar. <br></div><div><br></div><div>You see a=
 sensible declaration, and it gets modified by text way before. Likely hell=
 for tools, let alone humans. This way of application might fly for some at=
tribute, but not for this.<br></div><div><br></div><div><br></div><div> <br=
></div></div>

<p></p>

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

------=_Part_3287_1735023717.1539901854852--

------=_Part_3286_2101754663.1539901854852--

.


Author: mihailnajdenov@gmail.com
Date: Fri, 19 Oct 2018 00:34:19 -0700 (PDT)
Raw View
------=_Part_2239_770953848.1539934459932
Content-Type: multipart/alternative;
 boundary="----=_Part_2240_2099754643.1539934459932"

------=_Part_2240_2099754643.1539934459932
Content-Type: text/plain; charset="UTF-8"

I think the status quo should be rethought as we are moving to situation
where we need to specify explicitly, something that is effectively a
default. I am talking about Reflection. All reflection is compile time only.

If we need to mark every function as such this is clearly a design
deficiency.
How can a new language solve it? New type of function? A new type of
enclosing namespace or class?

With "All things constexpr" we are also moving to similar situation - All
of STL is constexpr and each and every function is decorated.
This is not good.

Even today something like a QPoint that can be constexpr must decorate
every and each function.

We could and should think of a better way.

May be we could decorate a namespace or a class and have a "reverse"
keyword to mark the exceptions of the rule.


--
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/91fb2dcc-8bac-40b3-8dff-6629ecb06b1a%40isocpp.org.

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

<div dir=3D"ltr">I think the status quo should be rethought as we are movin=
g to situation where we need to specify explicitly, something that is effec=
tively a default. I am talking about Reflection. All reflection is compile =
time only.<div><br></div><div>If we need to mark every function as such thi=
s is clearly a design deficiency.=C2=A0=C2=A0</div><div>How can a new langu=
age solve it? New type of function? A new type of enclosing namespace or cl=
ass?</div><div><br></div><div>With &quot;All things constexpr&quot; we are =
also moving to similar situation - All of STL is constexpr and each and eve=
ry function is decorated.</div><div>This is not good.</div><div><br></div><=
div>Even today something like a QPoint that can be constexpr must decorate =
every and each function.</div><div><br></div><div>We could and should think=
 of a better way.</div><div><br></div><div>May be we could decorate a names=
pace or a class and have a &quot;reverse&quot; keyword to mark the exceptio=
ns of the rule.</div><div><br></div><div><br></div></div>

<p></p>

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

------=_Part_2240_2099754643.1539934459932--

------=_Part_2239_770953848.1539934459932--

.


Author: pasa@lib.hu
Date: Fri, 19 Oct 2018 05:10:54 -0700 (PDT)
Raw View
------=_Part_3691_2121884599.1539951054824
Content-Type: multipart/alternative;
 boundary="----=_Part_3692_1921066758.1539951054824"

------=_Part_3692_1921066758.1539951054824
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



2018. okt=C3=B3ber 19., p=C3=A9ntek 9:34:20 UTC+2 id=C5=91pontban mihailn..=
..@gmail.com a=20
k=C3=B6vetkez=C5=91t =C3=ADrta:
>
> I think the status quo should be rethought as we are moving to situation=
=20
> where we need to specify explicitly, something that is effectively a=20
> default. I am talking about Reflection. All reflection is compile time on=
ly.
>
> If we need to mark every function as such this is clearly a design=20
> deficiency. =20
> How can a new language solve it? New type of function? A new type of=20
> enclosing namespace or class?
>
> With "All things constexpr" we are also moving to similar situation - All=
=20
> of STL is constexpr and each and every function is decorated.
> This is not good.
>
> Even today something like a QPoint that can be constexpr must decorate=20
> every and each function.
>
> We could and should think of a better way.
>
> May be we could decorate a namespace or a class and have a "reverse"=20
> keyword to mark the exceptions of the rule.
>

As I see, a facility to apply some tweak to a large region has a huge=20
demand. Including my paper P1112R0=20
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1112r0.pdf> if=20
you look at the very end. So I think instead of patching up individual=20
cases like mass consteval It would be better to have a solution supporting=
=20
multiple clients. Both already existing ones and coming in the future.  =20

As I mentioned before, it is mostly alien to the current language=20
structure, I found one feature that comes close, the   extern "C" {} block.=
=20
It is already in the language, the compilers need to deal with it and the=
=20
users are supposedly aware of related problems like moving the code in.out.=
=20

Maybe we could generalize that block  for different effects, including to=
=20
alter defaults, apply attributes or consteval.=20

I estimate it would be a scary feature, if not rejected right on, would=20
make 6-8 revisions...  but if coined it would make my everyday work much=20
easier.=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/6bcc1bdf-7aee-4300-9b7d-eb9e459c0552%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>2018. okt=C3=B3ber 19., p=C3=A9ntek 9:34:20 UTC+2 =
id=C5=91pontban mihailn...@gmail.com a k=C3=B6vetkez=C5=91t =C3=ADrta:<bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">I think the status=
 quo should be rethought as we are moving to situation where we need to spe=
cify explicitly, something that is effectively a default. I am talking abou=
t Reflection. All reflection is compile time only.<div><br></div><div>If we=
 need to mark every function as such this is clearly a design deficiency.=
=C2=A0=C2=A0</div><div>How can a new language solve it? New type of functio=
n? A new type of enclosing namespace or class?</div><div><br></div><div>Wit=
h &quot;All things constexpr&quot; we are also moving to similar situation =
- All of STL is constexpr and each and every function is decorated.</div><d=
iv>This is not good.</div><div><br></div><div>Even today something like a Q=
Point that can be constexpr must decorate every and each function.</div><di=
v><br></div><div>We could and should think of a better way.</div><div><br><=
/div><div>May be we could decorate a namespace or a class and have a &quot;=
reverse&quot; keyword to mark the exceptions of the rule.</div></div></bloc=
kquote><div><br></div><div>As I see, a facility to apply some tweak to a la=
rge region has a huge demand. Including my paper <a href=3D"http://www.open=
-std.org/jtc1/sc22/wg21/docs/papers/2018/p1112r0.pdf">P1112R0</a> if you lo=
ok at the very end. So I think instead of patching up individual cases like=
 mass consteval It would be better to have a solution supporting multiple c=
lients. Both already existing ones and coming in the future.=C2=A0=C2=A0 <b=
r></div><div><br></div><div>As I mentioned before, it is mostly alien to th=
e current language structure, I found one feature that comes close, the=C2=
=A0=C2=A0 extern &quot;C&quot; {} block. It is already in the language, the=
 compilers need to deal with it and the users are supposedly aware of relat=
ed problems like moving the code in.out. <br></div><div><br></div><div>Mayb=
e we could generalize that block=C2=A0 for different effects, including to =
alter defaults, apply attributes or consteval. <br></div><div><br></div><di=
v>I estimate it would be a scary feature, if not rejected right on, would m=
ake 6-8 revisions...=C2=A0 but if coined it would make my everyday work muc=
h easier. <br></div><div></div><div>=C2=A0</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/6bcc1bdf-7aee-4300-9b7d-eb9e459c0552%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6bcc1bdf-7aee-4300-9b7d-eb9e459c0552=
%40isocpp.org</a>.<br />

------=_Part_3692_1921066758.1539951054824--

------=_Part_3691_2121884599.1539951054824--

.


Author: mihailnajdenov@gmail.com
Date: Fri, 19 Oct 2018 07:04:49 -0700 (PDT)
Raw View
------=_Part_3584_744431244.1539957889798
Content-Type: multipart/alternative;
 boundary="----=_Part_3585_1491347160.1539957889798"

------=_Part_3585_1491347160.1539957889798
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



On Friday, October 19, 2018 at 3:10:54 PM UTC+3, pa...@lib.hu wrote:
>
>
>
> 2018. okt=C3=B3ber 19., p=C3=A9ntek 9:34:20 UTC+2 id=C5=91pontban mihailn=
....@gmail.com a=20
> k=C3=B6vetkez=C5=91t =C3=ADrta:
>>
>> I think the status quo should be rethought as we are moving to situation=
=20
>> where we need to specify explicitly, something that is effectively a=20
>> default. I am talking about Reflection. All reflection is compile time o=
nly.
>>
>> If we need to mark every function as such this is clearly a design=20
>> deficiency. =20
>> How can a new language solve it? New type of function? A new type of=20
>> enclosing namespace or class?
>>
>> With "All things constexpr" we are also moving to similar situation - Al=
l=20
>> of STL is constexpr and each and every function is decorated.
>> This is not good.
>>
>> Even today something like a QPoint that can be constexpr must decorate=
=20
>> every and each function.
>>
>> We could and should think of a better way.
>>
>> May be we could decorate a namespace or a class and have a "reverse"=20
>> keyword to mark the exceptions of the rule.
>>
>
> =20

> As I see, a facility to apply some tweak to a large region has a huge=20
> demand. Including my paper P1112R0=20
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1112r0.pdf> if=
=20
> you look at the very end. So I think instead of patching up individual=20
> cases like mass consteval It would be better to have a solution supportin=
g=20
> multiple clients. Both already existing ones and coming in the future.  =
=20
>
> As I mentioned before, it is mostly alien to the current language=20
> structure, I found one feature that comes close, the   extern "C" {} bloc=
k.=20
> It is already in the language, the compilers need to deal with it and the=
=20
> users are supposedly aware of related problems like moving the code in.ou=
t.=20
>
> Maybe we could generalize that block  for different effects, including to=
=20
> alter defaults, apply attributes or consteval.=20
>

Problem is, introducing a scope is a problem of its own - for instance it=
=20
can't be applied to a bulk of member functions.=20
All options should be evaluated, sadly it seems noone is working on this,=
=20
though now is the best time as the the needs is sky high and will only rise=
..

--=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/88979389-5cc8-4e28-902c-eb2512411b0e%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>On Friday, October 19, 2018 at 3:10:54 PM UTC+3, p=
a...@lib.hu wrote:<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"><br><br>2018. okt=C3=B3ber 19., p=C3=A9ntek 9:34:20 UTC+2 id=C5=91pont=
ban <a>mihailn...@gmail.com</a> a k=C3=B6vetkez=C5=91t =C3=ADrta:<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">I think the status quo shoul=
d be rethought as we are moving to situation where we need to specify expli=
citly, something that is effectively a default. I am talking about Reflecti=
on. All reflection is compile time only.<div><br></div><div>If we need to m=
ark every function as such this is clearly a design deficiency.=C2=A0=C2=A0=
</div><div>How can a new language solve it? New type of function? A new typ=
e of enclosing namespace or class?</div><div><br></div><div>With &quot;All =
things constexpr&quot; we are also moving to similar situation - All of STL=
 is constexpr and each and every function is decorated.</div><div>This is n=
ot good.</div><div><br></div><div>Even today something like a QPoint that c=
an be constexpr must decorate every and each function.</div><div><br></div>=
<div>We could and should think of a better way.</div><div><br></div><div>Ma=
y be we could decorate a namespace or a class and have a &quot;reverse&quot=
; keyword to mark the exceptions of the rule.</div></div></blockquote><div>=
<br></div></div></blockquote><div>=C2=A0</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><div>As I see, a facility to ap=
ply some tweak to a large region has a huge demand. Including my paper <a h=
ref=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1112r0.pdf"=
 target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://=
www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%=
2Fdocs%2Fpapers%2F2018%2Fp1112r0.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQj=
CNGB7eMn0iMfvtkRya71y9UBfVyhXw&#39;;return true;" onclick=3D"this.href=3D&#=
39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc=
22%2Fwg21%2Fdocs%2Fpapers%2F2018%2Fp1112r0.pdf\x26sa\x3dD\x26sntz\x3d1\x26u=
sg\x3dAFQjCNGB7eMn0iMfvtkRya71y9UBfVyhXw&#39;;return true;">P1112R0</a> if =
you look at the very end. So I think instead of patching up individual case=
s like mass consteval It would be better to have a solution supporting mult=
iple clients. Both already existing ones and coming in the future.=C2=A0=C2=
=A0 <br></div><div><br></div><div>As I mentioned before, it is mostly alien=
 to the current language structure, I found one feature that comes close, t=
he=C2=A0=C2=A0 extern &quot;C&quot; {} block. It is already in the language=
, the compilers need to deal with it and the users are supposedly aware of =
related problems like moving the code in.out. <br></div><div><br></div><div=
>Maybe we could generalize that block=C2=A0 for different effects, includin=
g to alter defaults, apply attributes or consteval. <br></div></div></block=
quote><div><br></div><div>Problem is, introducing a scope is a problem of i=
ts own - for instance it can&#39;t be applied to a bulk of member functions=
..=C2=A0</div><div>All options should be evaluated, sadly it seems noone is =
working on this, though now is the best time as the the needs is sky high a=
nd will only rise.</div><div><br></div></div>

<p></p>

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

------=_Part_3585_1491347160.1539957889798--

------=_Part_3584_744431244.1539957889798--

.