Topic: `pure` virt-specifier-seq to denote pure virtual functions.


Author: ezmagician@gmail.com
Date: Mon, 11 Jul 2016 14:31:59 -0700 (PDT)
Raw View
------=_Part_501_1155364340.1468272719348
Content-Type: multipart/alternative;
 boundary="----=_Part_502_599407637.1468272719349"

------=_Part_502_599407637.1468272719349
Content-Type: text/plain; charset=UTF-8

What are your thoughts on adding a new virt-specifier-seq specifying that a
function is pure virtual?

It would follow the same rules as the `override` and `final` specifiers.
This syntax would also allow a clear, simple syntax for in-class
definitions.

struct A {
//  In class pure virtual function definitions.
//  Follows same syntax as override and final specifiers, which are also
//  used to describe/enforce properties of virtual functions.
    virtual void foo() pure;
    virtual void bar() pure;

//  Allows for function definitions in the class declaration using the same
//  syntax as the override and final specifiers without the strange look of
//  previously suggested syntax of the form: void func() = 0 { }.
    virtual void ~A() pure = default;

//  Current syntax for denoting a pure function is strange.
//  This syntax is not used anywhere else in C++ (to my knowledge).
//  virtual void ~A() = 0;

//  Compiler error message seems to imply that a pure virtual function
//  cannot have a definition: "error: pure-specifier on function-definition"
//  virtual void bar() = 0 { };
};

// The current way to define a pure virtual function by overloading the
function
// outside the class declaration is non-intuitive.
// Danger of multiple definition errors if not inlined in a header.
// inline void A::A~() = default;

struct B : A {
    void foo() override final { }

//  pure specifier does not conflict with other virtual specifiers, although
//  the use of a pure-final function may be questionable.
    void bar() override pure;
};


--
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/4b8b5bd1-d8e2-4f70-bb83-96cc3dd519a9%40isocpp.org.

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

<div dir=3D"ltr"><div>What are your thoughts on adding a new virt-specifier=
-seq specifying that a function is pure virtual?<br></div><div><br></div><d=
iv>It would follow the same rules as the `override` and `final` specifiers.=
</div><div>This syntax would also allow a clear, simple syntax for in-class=
 definitions.</div><div><br></div><div><div class=3D"prettyprint" style=3D"=
border: 1px solid rgb(187, 187, 187); word-wrap: break-word; background-col=
or: rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=3D"subprett=
yprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">struct</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> A </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><span style=3D"co=
lor: #800;" class=3D"styled-by-prettify">// =C2=A0In class pure virtual fun=
ction definitions.</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br></span><span style=3D"color: #800;" class=3D"styled-by-prettify=
">// =C2=A0Follows same syntax as override and final specifiers, which are =
also</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></=
span><span style=3D"color: #800;" class=3D"styled-by-prettify">// =C2=A0use=
d to describe/enforce properties of virtual functions.</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">virtual</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">void</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> foo</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> pure</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled=
-by-prettify">virtual</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">void</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-prettify"> pure</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br><br></span><span style=3D"co=
lor: #800;" class=3D"styled-by-prettify">// =C2=A0Allows for function defin=
itions in the class declaration using the same</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #800;"=
 class=3D"styled-by-prettify">// =C2=A0syntax as the override and final spe=
cifiers without the strange look of</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br></span><span style=3D"color: #800;" class=3D"s=
tyled-by-prettify">// =C2=A0previously suggested syntax of the form: void f=
unc() =3D 0 { }.</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled=
-by-prettify">virtual</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">void</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">~</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify">A</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">()</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> pure </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">default</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br><br></span><span style=3D"color: #800;" class=3D"styled-by-prettify=
">// =C2=A0Current syntax for denoting a pure function is strange.</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span st=
yle=3D"color: #800;" class=3D"styled-by-prettify">// =C2=A0This syntax is n=
ot used anywhere else in C++ (to my knowledge).</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #800;=
" class=3D"styled-by-prettify">// =C2=A0virtual void ~A() =3D 0;</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><span =
style=3D"color: #800;" class=3D"styled-by-prettify">// =C2=A0Compiler error=
 message seems to imply that a pure virtual function</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: =
#800;" class=3D"styled-by-prettify">// =C2=A0cannot have a definition: &quo=
t;error: pure-specifier on function-definition&quot;</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: =
#800;" class=3D"styled-by-prettify">// =C2=A0virtual void bar() =3D 0 { };<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">};</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><span styl=
e=3D"color: #800;" class=3D"styled-by-prettify">// The current way to defin=
e a pure virtual function by overloading the function</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color:=
 #800;" class=3D"styled-by-prettify">// outside the class declaration is no=
n-intuitive. </span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br></span><span style=3D"color: #800;" class=3D"styled-by-prettify">// =
Danger of multiple definition errors if not inlined in a header.</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span styl=
e=3D"color: #800;" class=3D"styled-by-prettify">// inline void A::A~() =3D =
default;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">stru=
ct</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> B </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> A </span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">{</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">void</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"> foo</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">override</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">final</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><s=
pan style=3D"color: #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"><br><br></span><span style=3D"color: =
#800;" class=3D"styled-by-prettify">// =C2=A0pure specifier does not confli=
ct with other virtual specifiers, although</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #800;" cla=
ss=3D"styled-by-prettify">// =C2=A0the use of a pure-final function may be =
questionable.</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">void</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> bar</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(=
)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">override</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> pure</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">};</span></div></code></div><br><br></di=
v></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/4b8b5bd1-d8e2-4f70-bb83-96cc3dd519a9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4b8b5bd1-d8e2-4f70-bb83-96cc3dd519a9=
%40isocpp.org</a>.<br />

------=_Part_502_599407637.1468272719349--

------=_Part_501_1155364340.1468272719348--

.


Author: ezmagician@gmail.com
Date: Mon, 11 Jul 2016 14:59:54 -0700 (PDT)
Raw View
------=_Part_2865_1414590683.1468274394802
Content-Type: multipart/alternative;
 boundary="----=_Part_2866_16789300.1468274394802"

------=_Part_2866_16789300.1468274394802
Content-Type: text/plain; charset=UTF-8

In addition, should it follow the same rules as override and final, it
would not be considered a reserved keyword.
It would instead be an "identifier with special meaning" which only has
"special meaning in certain contexts."
I hope this is a good solution to the original reason
<https://stackoverflow.com/questions/2156634/why-pure-virtual-function-is-initialized-by-0/2156723#2156723> behind
why the `= 0` syntax was chosen to begin with.

On Monday, July 11, 2016 at 5:31:59 PM UTC-4, ezmag...@gmail.com wrote:
>
> What are your thoughts on adding a new virt-specifier-seq specifying that
> a function is pure virtual?
>
> It would follow the same rules as the `override` and `final` specifiers.
> This syntax would also allow a clear, simple syntax for in-class
> definitions.
>
> struct A {
> //  In class pure virtual function definitions.
> //  Follows same syntax as override and final specifiers, which are also
> //  used to describe/enforce properties of virtual functions.
>     virtual void foo() pure;
>     virtual void bar() pure;
>
> //  Allows for function definitions in the class declaration using the same
> //  syntax as the override and final specifiers without the strange look of
> //  previously suggested syntax of the form: void func() = 0 { }.
>     virtual void ~A() pure = default;
>
> //  Current syntax for denoting a pure function is strange.
> //  This syntax is not used anywhere else in C++ (to my knowledge).
> //  virtual void ~A() = 0;
>
> //  Compiler error message seems to imply that a pure virtual function
> //  cannot have a definition: "error: pure-specifier on
> function-definition"
> //  virtual void bar() = 0 { };
> };
>
> // The current way to define a pure virtual function by overloading the
> function
> // outside the class declaration is non-intuitive.
> // Danger of multiple definition errors if not inlined in a header.
> // inline void A::A~() = default;
>
> struct B : A {
>     void foo() override final { }
>
> //  pure specifier does not conflict with other virtual specifiers,
> although
> //  the use of a pure-final function may be questionable.
>     void bar() override pure;
> };
>
>
>

--
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/5467ba7d-88a0-43f7-a76c-919d66fcd60c%40isocpp.org.

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

<div dir=3D"ltr">In addition, should it follow the same rules as override a=
nd final, it would not be considered a reserved keyword.<div>It would inste=
ad be an &quot;identifier with special meaning&quot; which only has &quot;s=
pecial meaning in certain contexts.&quot;</div><div>I hope this is a good s=
olution to=C2=A0<a href=3D"https://stackoverflow.com/questions/2156634/why-=
pure-virtual-function-is-initialized-by-0/2156723#2156723">the original rea=
son</a>=C2=A0behind why the `=3D 0` syntax was chosen to begin with.</div><=
div><br>On Monday, July 11, 2016 at 5:31:59 PM UTC-4, ezmag...@gmail.com wr=
ote:<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>What=
 are your thoughts on adding a new virt-specifier-seq specifying that a fun=
ction is pure virtual?<br></div><div><br></div><div>It would follow the sam=
e rules as the `override` and `final` specifiers.</div><div>This syntax wou=
ld also allow a clear, simple syntax for in-class definitions.</div><div><b=
r></div><div><div style=3D"border:1px solid rgb(187,187,187);word-wrap:brea=
k-word;background-color:rgb(250,250,250)"><code><div><span style=3D"color:#=
008">struct</span><span style=3D"color:#000"> A </span><span style=3D"color=
:#660">{</span><span style=3D"color:#000"><br></span><span style=3D"color:#=
800">// =C2=A0In class pure virtual function definitions.</span><span style=
=3D"color:#000"><br></span><span style=3D"color:#800">// =C2=A0Follows same=
 syntax as override and final specifiers, which are also</span><span style=
=3D"color:#000"><br></span><span style=3D"color:#800">// =C2=A0used to desc=
ribe/enforce properties of virtual functions.</span><span style=3D"color:#0=
00"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008">virtual</span><span=
 style=3D"color:#000"> </span><span style=3D"color:#008">void</span><span s=
tyle=3D"color:#000"> foo</span><span style=3D"color:#660">()</span><span st=
yle=3D"color:#000"> pure</span><span style=3D"color:#660">;</span><span sty=
le=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008">virtu=
al</span><span style=3D"color:#000"> </span><span style=3D"color:#008">void=
</span><span style=3D"color:#000"> bar</span><span style=3D"color:#660">()<=
/span><span style=3D"color:#000"> pure</span><span style=3D"color:#660">;</=
span><span style=3D"color:#000"><br><br></span><span style=3D"color:#800">/=
/ =C2=A0Allows for function definitions in the class declaration using the =
same</span><span style=3D"color:#000"><br></span><span style=3D"color:#800"=
>// =C2=A0syntax as the override and final specifiers without the strange l=
ook of</span><span style=3D"color:#000"><br></span><span style=3D"color:#80=
0">// =C2=A0previously suggested syntax of the form: void func() =3D 0 { }.=
</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"c=
olor:#008">virtual</span><span style=3D"color:#000"> </span><span style=3D"=
color:#008">void</span><span style=3D"color:#000"> </span><span style=3D"co=
lor:#660">~</span><span style=3D"color:#000">A</span><span style=3D"color:#=
660">()</span><span style=3D"color:#000"> pure </span><span style=3D"color:=
#660">=3D</span><span style=3D"color:#000"> </span><span style=3D"color:#00=
8">default</span><span style=3D"color:#660">;</span><span style=3D"color:#0=
00"><br><br></span><span style=3D"color:#800">// =C2=A0Current syntax for d=
enoting a pure function is strange.</span><span style=3D"color:#000"><br></=
span><span style=3D"color:#800">// =C2=A0This syntax is not used anywhere e=
lse in C++ (to my knowledge).</span><span style=3D"color:#000"><br></span><=
span style=3D"color:#800">// =C2=A0virtual void ~A() =3D 0;</span><span sty=
le=3D"color:#000"><br><br></span><span style=3D"color:#800">// =C2=A0Compil=
er error message seems to imply that a pure virtual function</span><span st=
yle=3D"color:#000"><br></span><span style=3D"color:#800">// =C2=A0cannot ha=
ve a definition: &quot;error: pure-specifier on function-definition&quot;</=
span><span style=3D"color:#000"><br></span><span style=3D"color:#800">// =
=C2=A0virtual void bar() =3D 0 { };</span><span style=3D"color:#000"><br></=
span><span style=3D"color:#660">};</span><span style=3D"color:#000"><br><br=
></span><span style=3D"color:#800">// The current way to define a pure virt=
ual function by overloading the function</span><span style=3D"color:#000"><=
br></span><span style=3D"color:#800">// outside the class declaration is no=
n-intuitive. </span><span style=3D"color:#000"><br></span><span style=3D"co=
lor:#800">// Danger of multiple definition errors if not inlined in a heade=
r.</span><span style=3D"color:#000"><br></span><span style=3D"color:#800">/=
/ inline void A::A~() =3D default;</span><span style=3D"color:#000"><br><br=
></span><span style=3D"color:#008">struct</span><span style=3D"color:#000">=
 B </span><span style=3D"color:#660">:</span><span style=3D"color:#000"> A =
</span><span style=3D"color:#660">{</span><span style=3D"color:#000"><br>=
=C2=A0 =C2=A0 </span><span style=3D"color:#008">void</span><span style=3D"c=
olor:#000"> foo</span><span style=3D"color:#660">()</span><span style=3D"co=
lor:#000"> </span><span style=3D"color:#008">override</span><span style=3D"=
color:#000"> </span><span style=3D"color:#008">final</span><span style=3D"c=
olor:#000"> </span><span style=3D"color:#660">{</span><span style=3D"color:=
#000"> </span><span style=3D"color:#660">}</span><span style=3D"color:#000"=
><br><br></span><span style=3D"color:#800">// =C2=A0pure specifier does not=
 conflict with other virtual specifiers, although</span><span style=3D"colo=
r:#000"><br></span><span style=3D"color:#800">// =C2=A0the use of a pure-fi=
nal function may be questionable.</span><span style=3D"color:#000"><br>=C2=
=A0 =C2=A0 </span><span style=3D"color:#008">void</span><span style=3D"colo=
r:#000"> bar</span><span style=3D"color:#660">()</span><span style=3D"color=
:#000"> </span><span style=3D"color:#008">override</span><span style=3D"col=
or:#000"> pure</span><span style=3D"color:#660">;</span><span style=3D"colo=
r:#000"><br></span><span style=3D"color:#660">};</span></div></code></div><=
br><br></div></div></blockquote></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/5467ba7d-88a0-43f7-a76c-919d66fcd60c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5467ba7d-88a0-43f7-a76c-919d66fcd60c=
%40isocpp.org</a>.<br />

------=_Part_2866_16789300.1468274394802--

------=_Part_2865_1414590683.1468274394802--

.


Author: Greg Marr <gregmmarr@gmail.com>
Date: Mon, 11 Jul 2016 17:49:16 -0700 (PDT)
Raw View
------=_Part_3955_27497388.1468284556852
Content-Type: multipart/alternative;
 boundary="----=_Part_3956_1322019626.1468284556852"

------=_Part_3956_1322019626.1468284556852
Content-Type: text/plain; charset=UTF-8

On Monday, July 11, 2016 at 5:31:59 PM UTC-4, ezmag...@gmail.com wrote:
>
> What are your thoughts on adding a new virt-specifier-seq specifying that
> a function is pure virtual?
>

This was discussed here earlier this year.

https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/pure$20virtual/std-proposals/fsybBHRdKjI/zyj3_kj1GAAJ

I think it would be a good idea to add "= abstract" to replace the "= 0"
> syntax for pure virtual functions in a class. I believe it would be a good
> addition to the language, as It is more explicit in explaining what you are
> creating. It would make C++ look more unified in syntax as well, to match
> the "= default" and "= deleted" keywords added in C++11.



--
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/ddf39ddc-1dca-491d-81f1-67f2993918b0%40isocpp.org.

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

<div dir=3D"ltr">On Monday, July 11, 2016 at 5:31:59 PM UTC-4, ezmag...@gma=
il.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div>What are your thoughts on adding a new virt-specifier-seq specifying t=
hat a function is pure virtual?</div></div></blockquote><div><br></div><div=
>This was discussed here earlier this year.</div><div><br></div><div>https:=
//groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/pure$20virt=
ual/std-proposals/fsybBHRdKjI/zyj3_kj1GAAJ</div><div><br></div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width=
: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); pad=
ding-left: 1ex;">I think it would be a good idea to add &quot;=3D abstract&=
quot; to replace the &quot;=3D 0&quot; syntax for pure virtual functions in=
 a class. I believe it would be a good addition to the language, as It is m=
ore explicit in explaining what you are creating. It would make C++ look mo=
re unified in syntax as well, to match the &quot;=3D default&quot; and &quo=
t;=3D deleted&quot; keywords added in C++11.</blockquote><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/ddf39ddc-1dca-491d-81f1-67f2993918b0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ddf39ddc-1dca-491d-81f1-67f2993918b0=
%40isocpp.org</a>.<br />

------=_Part_3956_1322019626.1468284556852--

------=_Part_3955_27497388.1468284556852--

.


Author: ezmagician@gmail.com
Date: Mon, 11 Jul 2016 18:37:25 -0700 (PDT)
Raw View
------=_Part_442_1826891075.1468287445394
Content-Type: multipart/alternative;
 boundary="----=_Part_443_749412434.1468287445394"

------=_Part_443_749412434.1468287445394
Content-Type: text/plain; charset=UTF-8

I looked through that discussion prior to posting this, and believe this
suggestion to be different enough from the suggestions posted there.

The earlier post proposed using a keyword "abstract" to define a function
akin to the default and delete keywords.
To be consistent with their usage, it proposed that the syntax be similar
to default and delete: "void foo() = abstract."

However, I disagree with the following quote:
> Because = 0, = default and = delete all define this function,
> while the current context sensitive keywords virtual and
> override qualifies a signature, no matter whether it's a
> definition.  So = abstract looks following this trend.

I believe that `pure` as a virt-specifier (override and final) would be
more appropriate than default or delete.
Default and delete are used in regards to the *definition* of the function.
I believe `pure` is closer to override and final, where it is used to
describe properties of a virtual function.
In that respect, `= 0` already behaves as if it were a virt-specifier, even
if it is not one yet.
If, as the above quote claims, `= 0` "defines" the function, then defining
a pure virtual function should be an error.

However, `= 0` does not actually "define" the function, but only specifies
that the function is pure.
This is evidenced by the ability to define a pure virtual function by
writing a definition outside the class declaration.
There are replies in the original post that supporting this sentiment.

The old post also does not discuss how their proposed syntax would work
together with a definition.
This proposal would allow one to define a pure virtual function using a
syntax that is already consistently in use.
Also, thanks to virt-specifiers having meaning only in their specific
context, the implementation should be backwards-compatible.

On Monday, July 11, 2016 at 8:49:17 PM UTC-4, Greg Marr wrote:
>
> On Monday, July 11, 2016 at 5:31:59 PM UTC-4, ezmag...@gmail.com wrote:
>>
>> What are your thoughts on adding a new virt-specifier-seq specifying that
>> a function is pure virtual?
>>
>
> This was discussed here earlier this year.
>
>
> https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/pure$20virtual/std-proposals/fsybBHRdKjI/zyj3_kj1GAAJ
>
> I think it would be a good idea to add "= abstract" to replace the "= 0"
>> syntax for pure virtual functions in a class. I believe it would be a good
>> addition to the language, as It is more explicit in explaining what you are
>> creating. It would make C++ look more unified in syntax as well, to match
>> the "= default" and "= deleted" keywords added in C++11.
>
>
>

--
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/9965649e-353f-45fb-8e8a-59c22f182534%40isocpp.org.

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

<div dir=3D"ltr">I looked through that discussion prior to posting this, an=
d believe this suggestion to be different enough from the suggestions poste=
d there.<div><br></div><div>The earlier post proposed using a keyword &quot=
;abstract&quot; to define a function akin to the default and delete keyword=
s.</div><div>To be consistent with their usage, it proposed that the syntax=
 be similar to default and delete: &quot;void foo() =3D abstract.&quot;</di=
v><div><br></div><div>However, I disagree with the following quote:</div><d=
iv>&gt; Because =3D 0, =3D default and =3D delete all define this function,=
=C2=A0<br>&gt; while the current context sensitive keywords virtual and=C2=
=A0<br>&gt; override qualifies a signature, no matter whether it&#39;s a=C2=
=A0<br>&gt; definition. =C2=A0So =3D abstract looks following this trend.=
=C2=A0<br></div><div><br></div><div>I believe that `pure` as a virt-specifi=
er (override and final) would be more appropriate than default or delete.</=
div><div>Default and delete are used in regards to the <b>definition</b>=C2=
=A0of the function.</div><div>I believe `pure` is closer to override and fi=
nal, where it is used to describe properties of a virtual function.</div><d=
iv>In that respect, `=3D 0` already behaves as if it were a virt-specifier,=
 even if it is not one yet.</div><div>If, as the above quote claims, `=3D 0=
` &quot;defines&quot; the function, then defining a pure virtual function s=
hould be an error.</div><div><br></div><div>However, `=3D 0` does not actua=
lly &quot;define&quot; the function, but only specifies that the function i=
s pure.</div><div>This is evidenced by the ability to define a pure virtual=
 function by writing a definition outside the class declaration.</div><div>=
There are replies in the original post that supporting this sentiment.</div=
><div><br></div><div>The old post also does not discuss how their proposed =
syntax would work together with a definition.</div><div>This proposal would=
 allow one to define a pure virtual function using a syntax that is already=
 consistently in use.</div><div>Also, thanks to virt-specifiers having mean=
ing only in their specific context, the implementation should be backwards-=
compatible.</div><div><div><br>On Monday, July 11, 2016 at 8:49:17 PM UTC-4=
, Greg Marr 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">On Monday, July 11, 2016 at 5:31:59 PM UTC-4, <a>ezmag...@gmail.com</a=
> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>What =
are your thoughts on adding a new virt-specifier-seq specifying that a func=
tion is pure virtual?</div></div></blockquote><div><br></div><div>This was =
discussed here earlier this year.</div><div><br></div><div><a href=3D"https=
://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/pure$20vir=
tual/std-proposals/fsybBHRdKjI/zyj3_kj1GAAJ" target=3D"_blank" rel=3D"nofol=
low" onmousedown=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org=
/forum/#!searchin/std-proposals/pure$20virtual/std-proposals/fsybBHRdKjI/zy=
j3_kj1GAAJ&#39;;return true;" onclick=3D"this.href=3D&#39;https://groups.go=
ogle.com/a/isocpp.org/forum/#!searchin/std-proposals/pure$20virtual/std-pro=
posals/fsybBHRdKjI/zyj3_kj1GAAJ&#39;;return true;">https://groups.google.co=
m/a/<wbr>isocpp.org/forum/#!searchin/<wbr>std-proposals/pure$20virtual/<wbr=
>std-proposals/fsybBHRdKjI/<wbr>zyj3_kj1GAAJ</a></div><div><br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-w=
idth:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding=
-left:1ex">I think it would be a good idea to add &quot;=3D abstract&quot; =
to replace the &quot;=3D 0&quot; syntax for pure virtual functions in a cla=
ss. I believe it would be a good addition to the language, as It is more ex=
plicit in explaining what you are creating. It would make C++ look more uni=
fied in syntax as well, to match the &quot;=3D default&quot; and &quot;=3D =
deleted&quot; keywords added in C++11.</blockquote><div>=C2=A0</div></div><=
/blockquote></div></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/9965649e-353f-45fb-8e8a-59c22f182534%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9965649e-353f-45fb-8e8a-59c22f182534=
%40isocpp.org</a>.<br />

------=_Part_443_749412434.1468287445394--

------=_Part_442_1826891075.1468287445394--

.


Author: Greg Marr <gregmmarr@gmail.com>
Date: Mon, 11 Jul 2016 19:53:32 -0700 (PDT)
Raw View
------=_Part_315_1813374239.1468292012186
Content-Type: multipart/alternative;
 boundary="----=_Part_316_1056714144.1468292012187"

------=_Part_316_1056714144.1468292012187
Content-Type: text/plain; charset=UTF-8

These are the parts of that thread that I think are most important:

Matt Calabrese
I do not see sufficient motivation for this change. 0 in this context is
symbolic and pretty reasonable, in my opinion. Using "abstract" instead of
0 doesn't solve any practical problems ... . As far as I can tell, what you
describe is purely just an additional syntax for something that can already
be done in the language, and this syntax does not provide tangible benefit.
I personally do not agree that it is more clear, either, though it
certainly is more verbose, and I have doubts that it is at all easier to
teach. In either way, someone has to learn that "= 0" or "= abstract" means
that it's a pure virtual function, and I don't see why one would say that
either one of those options is strictly better. The harder part when
learning is understanding what a pure virtual function *is* as opposed to
the specific spelling of "pure virtual."
Ville Voutilainen
Also, adding a second syntax to do the exact same thing as another syntax
increases the knowledge needed for code readers to understand C++.


--
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/69414d97-dbaf-4ba4-b8fa-17bc5279b402%40isocpp.org.

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

<div dir=3D"ltr">These are the parts of that thread that I think are most i=
mportant:=C2=A0<div><br></div><div><div class=3D"IVILX2C-fd-a"><div tabinde=
x=3D"0" class=3D"IVILX2C-tb-P"><div style=3D"overflow: auto;"><div style=3D=
"max-height: 10000px;"><div dir=3D"ltr"><div class=3D"gmail_quote"><span cl=
ass=3D"_username" style=3D"color: rgb(136, 136, 136); line-height: 19.5px;"=
><span class=3D"IVILX2C-D-a g-hovercard" data-userid=3D"1086178298591662165=
52" data-name=3D"Matt Calabrese" style=3D"color: rgb(34, 34, 34);">Matt Cal=
abrese</span></span><span style=3D"color: rgb(136, 136, 136); line-height: =
19.5px;">=C2=A0</span><br class=3D"Apple-interchange-newline">I do not see =
sufficient motivation for this change. 0 in this context is symbolic and pr=
etty reasonable, in my opinion. Using &quot;abstract&quot; instead of 0 doe=
sn&#39;t solve any practical problems ... . As far as I can tell, what you =
describe is purely just an additional syntax for something that can already=
 be done in the language, and this syntax does not provide tangible benefit=
.. I personally do not agree that it is more clear, either, though it certai=
nly is more verbose, and I have doubts that it is at all easier to teach. I=
n either way, someone has to learn that &quot;=3D 0&quot; or &quot;=3D abst=
ract&quot; means that it&#39;s a pure virtual function, and I don&#39;t see=
 why one would say that either one of those options is strictly better. The=
 harder part when learning is understanding what a pure virtual function *i=
s* as opposed to the specific spelling of &quot;pure virtual.&quot;</div></=
div></div></div></div><div></div><div></div></div><div><div class=3D"IVILX2=
C-fd-a"></div></div><div class=3D"IVILX2C-tb-b"><div class=3D"IVILX2C-tb-a =
IVILX2C-tb-cb"></div><div class=3D"IVILX2C-tb-a IVILX2C-tb-cb"><span style=
=3D"font-weight: bold; line-height: 19.5px; white-space: nowrap;">Ville Vou=
tilainen</span><br></div><div class=3D"IVILX2C-tb-a IVILX2C-tb-cb">Also, ad=
ding a second syntax to do the exact same thing as another syntax increases=
 the knowledge needed for code readers to understand C++.<br clear=3D"all">=
</div><div><br></div><div><br></div></div></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/69414d97-dbaf-4ba4-b8fa-17bc5279b402%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/69414d97-dbaf-4ba4-b8fa-17bc5279b402=
%40isocpp.org</a>.<br />

------=_Part_316_1056714144.1468292012187--

------=_Part_315_1813374239.1468292012186--

.


Author: ezmagician@gmail.com
Date: Tue, 12 Jul 2016 14:03:07 -0700 (PDT)
Raw View
------=_Part_83_1415908611.1468357387861
Content-Type: multipart/alternative;
 boundary="----=_Part_84_639364967.1468357387862"

------=_Part_84_639364967.1468357387862
Content-Type: text/plain; charset=UTF-8

I agree with the reasoning, but...

As far as I can tell, what you describe is purely just an additional syntax
> for something that can already be done in the language, and this syntax
> does not provide tangible benefit.


.... I believe there are two benefits that this provides (the crux of my
proposal, I suppose):

   - It would encourage learning the `abstract` specifier along with the
   `override` and `final` specifiers as a group of keywords used together in
   enforcing good and proper usage of virtual functions.
   - It would allow for writing definitions for pure virtual functions
   without being required to define them outside the class declaration in a
   consistent manner with other C++ code.

If these two points are not enough for this to be worth considering, then I
admit to having nothing else to offer in support of this suggestion either.

On Monday, July 11, 2016 at 10:53:32 PM UTC-4, Greg Marr wrote:
>
> These are the parts of that thread that I think are most important:
>
> Matt Calabrese
> I do not see sufficient motivation for this change. 0 in this context is
> symbolic and pretty reasonable, in my opinion. Using "abstract" instead of
> 0 doesn't solve any practical problems ... . As far as I can tell, what you
> describe is purely just an additional syntax for something that can already
> be done in the language, and this syntax does not provide tangible benefit.
> I personally do not agree that it is more clear, either, though it
> certainly is more verbose, and I have doubts that it is at all easier to
> teach. In either way, someone has to learn that "= 0" or "= abstract" means
> that it's a pure virtual function, and I don't see why one would say that
> either one of those options is strictly better. The harder part when
> learning is understanding what a pure virtual function *is* as opposed to
> the specific spelling of "pure virtual."
> Ville Voutilainen
> Also, adding a second syntax to do the exact same thing as another syntax
> increases the knowledge needed for code readers to understand C++.
>
>
>

--
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/6453efc8-ce7e-40e1-9cd7-366b9871e025%40isocpp.org.

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

<div dir=3D"ltr">I agree with the reasoning, but...<div><br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-wi=
dth: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); =
padding-left: 1ex;">As far as I can tell, what you describe is purely just =
an additional syntax for something that can already be done in the language=
, and this syntax does not provide tangible benefit.</blockquote><div><br><=
/div><div>... I believe there are two benefits that this provides (the crux=
 of my proposal, I suppose):</div><div><ul><li><span style=3D"line-height: =
normal;">It would encourage learning the `abstract` specifier along with th=
e `override` and `final` specifiers as a group of keywords used together in=
 enforcing good and proper usage of virtual functions.</span></li><li><span=
 style=3D"line-height: normal;">It would allow for writing definitions for =
pure virtual functions without being required to define them outside the cl=
ass declaration in a consistent manner with other C++ code.</span></li></ul=
><div>If these two points are not enough for this to be worth considering, =
then I admit to having nothing else to offer in support of this suggestion =
either.</div><br>On Monday, July 11, 2016 at 10:53:32 PM UTC-4, Greg Marr w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">These ar=
e the parts of that thread that I think are most important:=C2=A0<div><br><=
/div><div><div><div><div style=3D"overflow:auto"><div style=3D"max-height:1=
0000px"><div dir=3D"ltr"><div class=3D"gmail_quote"><span style=3D"color:rg=
b(136,136,136);line-height:19.5px"><span style=3D"color:rgb(34,34,34)">Matt=
 Calabrese</span></span><span style=3D"color:rgb(136,136,136);line-height:1=
9.5px">=C2=A0</span><br>I do not see sufficient motivation for this change.=
 0 in this context is symbolic and pretty reasonable, in my opinion. Using =
&quot;abstract&quot; instead of 0 doesn&#39;t solve any practical problems =
.... . As far as I can tell, what you describe is purely just an additional =
syntax for something that can already be done in the language, and this syn=
tax does not provide tangible benefit. I personally do not agree that it is=
 more clear, either, though it certainly is more verbose, and I have doubts=
 that it is at all easier to teach. In either way, someone has to learn tha=
t &quot;=3D 0&quot; or &quot;=3D abstract&quot; means that it&#39;s a pure =
virtual function, and I don&#39;t see why one would say that either one of =
those options is strictly better. The harder part when learning is understa=
nding what a pure virtual function *is* as opposed to the specific spelling=
 of &quot;pure virtual.&quot;</div></div></div></div></div><div></div><div>=
</div></div><div><div></div></div><div><div></div><div><span style=3D"font-=
weight:bold;line-height:19.5px;white-space:nowrap">Ville Voutilainen</span>=
<br></div><div>Also, adding a second syntax to do the exact same thing as a=
nother syntax increases the knowledge needed for code readers to understand=
 C++.<br clear=3D"all"></div><div><br></div><div><br></div></div></div></di=
v></blockquote></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/6453efc8-ce7e-40e1-9cd7-366b9871e025%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6453efc8-ce7e-40e1-9cd7-366b9871e025=
%40isocpp.org</a>.<br />

------=_Part_84_639364967.1468357387862--

------=_Part_83_1415908611.1468357387861--

.


Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Wed, 13 Jul 2016 10:05:25 -0400
Raw View
On 2016-07-12 16:58, D. B. wrote:
> On Tue, Jul 12, 2016 at 5:20 PM, Tony V E wrote:
>> On Mon, Jul 11, 2016 at 11:40 PM, Ricardo Fabiano de Andrade wrote:
>>
>>> On top of that, `pure` some may want using it with the same meaning as it
>>> has in D:
>>> https://dlang.org/spec/function.html#pure-functions
>>
>> Definitely.
>
> *Why?* C++ and D are unrelated. Why should C++ start doing things just
> because some other language does?

Ahem. To rephrase, some people might want `pure` to have the same or
similar meaning in ISO C++ as it does for GCC and clang, and as in the
general fields of computer science and mathematics. (As well as,
incidentally, some other programming languages, including D. And Fortran.)

To wit: https://en.wikipedia.org/wiki/Pure_function (note that this is
NOT specific to a particular programming language!).

--
Matthew

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

.