------=_Part_1548_1246757014.1468535888982
Content-Type: multipart/alternative;
 boundary="----=_Part_1549_1943275879.1468535888982"

------=_Part_1549_1943275879.1468535888982
Content-Type: text/plain; charset=UTF-8

Similar to the "const" specifier that prevents calling a non-const member
function, I would like a specifier that indicates that a function is a
nonblocking function and can only call other nonblocking functions. This
would prevent a whole class of bugs in multithreaded applications.

Another person had a similar idea but thought a more general solution of
allowing custom type modifiers might be better:
http://allievi.sssup.it/techblog/archives/705

Has anything like this been proposed?

    Derek

--
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/208e435f-6aef-44f8-803a-f9fdabd7f48c%40isocpp.org.

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

<div dir=3D"ltr">Similar to the &quot;const&quot; specifier that prevents c=
alling a non-const member function, I would like a specifier that indicates=
 that a function is a nonblocking function and can only call other nonblock=
ing functions. This would prevent a whole class of bugs in multithreaded ap=
plications.<br><br>Another person had a similar idea but thought a more gen=
eral solution of allowing custom type modifiers might be better: http://all=
ievi.sssup.it/techblog/archives/705<br><br>Has anything like this been prop=
osed?<br><br>=C2=A0=C2=A0=C2=A0 Derek<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/208e435f-6aef-44f8-803a-f9fdabd7f48c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/208e435f-6aef-44f8-803a-f9fdabd7f48c=
%40isocpp.org</a>.<br />

------=_Part_1549_1943275879.1468535888982--

------=_Part_1548_1246757014.1468535888982--

.

On quinta-feira, 14 de julho de 2016 15:38:08 PDT Derek Hofmann wrote:
> Similar to the "const" specifier that prevents calling a non-const member
> function, I would like a specifier that indicates that a function is a
> nonblocking function and can only call other nonblocking functions. This
> would prevent a whole class of bugs in multithreaded applications.
>
> Another person had a similar idea but thought a more general solution of
> allowing custom type modifiers might be better:
> http://allievi.sssup.it/techblog/archives/705
>
> Has anything like this been proposed?

For the first time since I've been a member of this mailing list, I think we
can safely say that this IS a good use of attributes.

This is like the [[pure]] attribute that was proposed but not yet accepted.
But unlike the [[pure]] attribute, this is just a compiler-aided check.

Maybe you can widen your proposal to something like attribute
[[ensures(xxx)]], which can only call other functions that have the same xxx
in their [[ensures(...)]] declaration. This would allow for different tags,
not just "nonblocking".

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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/5902481.5sOy2UxVOc%40tjmaciei-mobl1.

.

On quinta-feira, 14 de julho de 2016 16:49:38 PDT Thiago Macieira wrote:
> > Another person had a similar idea but thought a more general solution of
> > allowing custom type modifiers might be better:
> > http://allievi.sssup.it/techblog/archives/705
> >
> > Has anything like this been proposed?

> Maybe you can widen your proposal to something like attribute
> [[ensures(xxx)]], which can only call other functions that have the same
> xxx  in their [[ensures(...)]] declaration. This would allow for different
> tags, not just "nonblocking".

Uh... which is what you had said.

This can also go further and be used for types, allowing the compiler to
complain when you mix two objects of the same type, but not of the same "tag".
You can see an example of that in the Linux kernel, where user pointers are
marked __user and there's some tool somewhere that checks whether you made an
assignment you shouldn't have.

This would also require a library function to "launder" the type and erase the
attributes.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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/1633901.mlcr9IcRSI%40tjmaciei-mobl1.

.

------=_Part_2623_742081376.1468603341664
Content-Type: multipart/alternative;
 boundary="----=_Part_2624_740794781.1468603341665"

------=_Part_2624_740794781.1468603341665
Content-Type: text/plain; charset=UTF-8

Thiago,

Thanks for the words of support.

Thinking about this a little more, in order to mix well with old code, it
needs a way to override the absence of the specifier or attribute in the
way that "const_cast" and "mutable" override "const". I was thinking that
blocks (scopes) of code within a function could be tagged as conformant
with the specifier or attribute:

    void BlockingFunc() // All functions are considered to be blocking by
default
    {
    }

    [[ensures(nonblocking)]] void NonblockingFunc()
    {
    }

    [[ensures(nonblocking)]] void MyFunc()
    {
        BlockingFunc(); // error: "nonblocking" attribute not specified

        conforms(nonblocking)
        {
            BlockingFunc(); // no error
        }

        NonblockingFunc(); // no error
    }


But a simple conversion cast should also work:

    [[ensures(nonblocking)]] void MyFunc()
    {
        conform_cast<nonblocking>( BlockingFunc() ); // no error
    }

Which of the two works better, or is there a better way to mix with old
code than either example above?

    Derek

On Thursday, July 14, 2016 at 5:05:27 PM UTC-7, Thiago Macieira wrote:
>
> On quinta-feira, 14 de julho de 2016 16:49:38 PDT Thiago Macieira wrote:
> > > Another person had a similar idea but thought a more general solution
> of
> > > allowing custom type modifiers might be better:
> > > http://allievi.sssup.it/techblog/archives/705
> > >
> > > Has anything like this been proposed?
>
> > Maybe you can widen your proposal to something like attribute
> > [[ensures(xxx)]], which can only call other functions that have the same
> > xxx  in their [[ensures(...)]] declaration. This would allow for
> different
> > tags, not just "nonblocking".
>
> Uh... which is what you had said.
>
> This can also go further and be used for types, allowing the compiler to
> complain when you mix two objects of the same type, but not of the same
> "tag".
> You can see an example of that in the Linux kernel, where user pointers
> are
> marked __user and there's some tool somewhere that checks whether you made
> an
> assignment you shouldn't have.
>
> This would also require a library function to "launder" the type and erase
> the
> attributes.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>
>

--
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/20a51784-3ec9-4118-9c8e-135add6c3e58%40isocpp.org.

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

<div dir=3D"ltr">Thiago,<br><br>Thanks for the words of support.<br><br>Thi=
nking about this a little more, in order to mix well with old code, it need=
s a way to override the absence of the specifier or attribute in the way th=
at &quot;const_cast&quot; and &quot;mutable&quot; override &quot;const&quot=
;. I was thinking that blocks (scopes) of code within a function could be t=
agged as conformant with the specifier or attribute:<br><br><div class=3D"p=
rettyprint" style=3D"background-color: rgb(250, 250, 250); border-color: rg=
b(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-=
word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">=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"> </span><span style=3D"color=
: #606;" class=3D"styled-by-prettify">BlockingFunc</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: #800;" class=
=3D"styled-by-prettify">// All functions are considered to be </span><span =
style=3D"color: #800;" class=3D"styled-by-prettify">blocking by default</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=
=A0 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=
=A0 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>=C2=A0 =
=C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">[[<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">ensures</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">nonblocking</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">void</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">NonblockingFunc</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: #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: #660;" c=
lass=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br><br>=C2=A0 =C2=A0 </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">[[</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">ensures</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">nonblocking</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">)]]</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">voi=
d</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #606;" class=3D"styled-by-prettify">MyFunc</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><sp=
an 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 =C2=A0 =C2=
=A0 </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Blocki=
ngFunc</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: #800;" class=3D"styled-by-prettify">// error: &quot;nonb=
locking&quot; attribute not specified</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 conforms</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">nonblocking</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 =C2=A0 =C2=A0=
 </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 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #606;" class=3D"st=
yled-by-prettify">BlockingFunc</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: #800;" class=3D"styled-by-pretti=
fy">// no error</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D=
"color: #606;" class=3D"styled-by-prettify">NonblockingFunc</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">();</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #80=
0;" class=3D"styled-by-prettify">// no error</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">}</span></div></code></div><br><b=
r>But a simple conversion cast should also work:<br><br><div class=3D"prett=
yprint" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(18=
7, 187, 187); border-style: solid; border-width: 1px; 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 styl=
e=3D"color: #660;" class=3D"styled-by-prettify">[[</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">ensures</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify">nonblocking</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">void</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">=
MyFunc</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: #660;" class=3D"styled-by-prettify">{</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 conform_cast</span><span style=3D"color: #080;" class=
=3D"styled-by-prettify">&lt;nonblocking&gt;</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"style=
d-by-prettify">BlockingFunc</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </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: #800;" class=3D"styled-by-prettify">// no error</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=
=A0 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</spa=
n></div></code></div><br>Which of the two works better, or is there a bette=
r way to mix with old code than either example above?<br><br>=C2=A0=C2=A0=
=C2=A0 Derek<br><br>On Thursday, July 14, 2016 at 5:05:27 PM UTC-7, Thiago =
Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On quinta-feira=
, 14 de julho de 2016 16:49:38 PDT Thiago Macieira wrote:
<br>&gt; &gt; Another person had a similar idea but thought a more general =
solution of
<br>&gt; &gt; allowing custom type modifiers might be better:
<br>&gt; &gt; <a href=3D"http://allievi.sssup.it/techblog/archives/705" tar=
get=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.=
google.com/url?q\x3dhttp%3A%2F%2Fallievi.sssup.it%2Ftechblog%2Farchives%2F7=
05\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFcFHW4GRe2zGcN41oQ2z28XuVmCQ&#39=
;;return true;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\x3d=
http%3A%2F%2Fallievi.sssup.it%2Ftechblog%2Farchives%2F705\x26sa\x3dD\x26snt=
z\x3d1\x26usg\x3dAFQjCNFcFHW4GRe2zGcN41oQ2z28XuVmCQ&#39;;return true;">http=
://allievi.sssup.it/<wbr>techblog/archives/705</a>
<br>&gt; &gt;=20
<br>&gt; &gt; Has anything like this been proposed?
<br>
<br>&gt; Maybe you can widen your proposal to something like attribute=20
<br>&gt; [[ensures(xxx)]], which can only call other functions that have th=
e same
<br>&gt; xxx =C2=A0in their [[ensures(...)]] declaration. This would allow =
for different
<br>&gt; tags, not just &quot;nonblocking&quot;.
<br>
<br>Uh... which is what you had said.
<br>
<br>This can also go further and be used for types, allowing the compiler t=
o=20
<br>complain when you mix two objects of the same type, but not of the same=
 &quot;tag&quot;.=20
<br>You can see an example of that in the Linux kernel, where user pointers=
 are=20
<br>marked __user and there&#39;s some tool somewhere that checks whether y=
ou made an=20
<br>assignment you shouldn&#39;t have.
<br>
<br>This would also require a library function to &quot;launder&quot; the t=
ype and erase the=20
<br>attributes.
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return true;" onclick=3D"this.hr=
ef=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return t=
rue;">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
GRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;" onclick=3D"this.href=3D&#39;=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;">kde.org</a=
>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br></blockquote></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/20a51784-3ec9-4118-9c8e-135add6c3e58%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/20a51784-3ec9-4118-9c8e-135add6c3e58=
%40isocpp.org</a>.<br />

------=_Part_2624_740794781.1468603341665--

------=_Part_2623_742081376.1468603341664--

.

------=_Part_3140_1977812641.1468620233160
Content-Type: multipart/alternative;
 boundary="----=_Part_3141_1569879720.1468620233160"

------=_Part_3141_1569879720.1468620233160
Content-Type: text/plain; charset=UTF-8

That's a good catch, inkwizyt.

Besides "nonblocking", another tag people might want to use is "reentrant".
And there's already a topic about it:
https://groups.google.com/a/isocpp.org/d/msg/std-proposals/yBLLDuf_1ck/cBIYsZRepvEJ

On Friday, July 15, 2016 at 12:51:19 PM UTC-7, inkwizyt...@gmail.com wrote:
>
>
> I think you use incorrect syntax. Because "nonblocking" is attribute then
> disabling it should be too.
>
> Proper syntax should be something like that:
> [[ensures(nonblocking)]] void MyFunc()
> {
>   int x = [[ignore(nonblocking)]] funcA();
>   [[ignore(nonblocking)]]
>   {
>     funcB();
>     funcV();
>   }
> }
>
>
>

--
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/3c022697-0886-493b-bda2-3648bcdacabb%40isocpp.org.

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

<div dir=3D"ltr">That&#39;s a good catch, inkwizyt.<br><br>Besides &quot;no=
nblocking&quot;, another tag people might want to use is &quot;reentrant&qu=
ot;. And there&#39;s already a topic about it: https://groups.google.com/a/=
isocpp.org/d/msg/std-proposals/yBLLDuf_1ck/cBIYsZRepvEJ<br><br>On Friday, J=
uly 15, 2016 at 12:51:19 PM UTC-7, inkwizyt...@gmail.com wrote:<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><br>I think you use =
incorrect syntax. Because &quot;<code><span style=3D"color:#660"></span><sp=
an style=3D"color:#000">nonblocking</span><span style=3D"color:#660"></span=
></code>&quot; is attribute then disabling it should be too.<br><br>Proper =
syntax should be something like that:<br><div 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><div><span style=3D"color:#660">[[</span><=
span style=3D"color:#000">ensures</span><span style=3D"color:#660">(</span>=
<span style=3D"color:#000">nonblocking</span><span style=3D"color:#660">)]]=
</span><span style=3D"color:#000"> </span><span style=3D"color:#008">void</=
span><span style=3D"color:#000"> </span><span style=3D"color:#606">MyFunc</=
span><span style=3D"color:#660">()</span><span style=3D"color:#000"><br></s=
pan><span style=3D"color:#660">{</span><span style=3D"color:#000"> <br>=C2=
=A0 </span><span style=3D"color:#008">int</span><span style=3D"color:#000">=
 x </span><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> =
</span><span style=3D"color:#660">[[</span><span style=3D"color:#000">ignor=
e</span><span style=3D"color:#660">(</span><code><span style=3D"color:#660"=
></span><span style=3D"color:#000"><span style=3D"color:#000">nonblocking</=
span></span><span style=3D"color:#660"></span></code><span style=3D"color:#=
660">)]]</span><span style=3D"color:#000"> funcA</span><span style=3D"color=
:#660">();</span><span style=3D"color:#000"><br>=C2=A0 </span><span style=
=3D"color:#660">[[</span><span style=3D"color:#000">ignore</span><span styl=
e=3D"color:#660">(</span><span style=3D"color:#000">nonblocking</span><span=
 style=3D"color:#660">)]]</span><span style=3D"color:#000"><br>=C2=A0 </spa=
n><span style=3D"color:#660">{</span><span style=3D"color:#000"><br>=C2=A0 =
=C2=A0 funcB</span><span style=3D"color:#660">();</span><span style=3D"colo=
r:#000"><br>=C2=A0 =C2=A0 funcV</span><span style=3D"color:#660">();</span>=
<span style=3D"color:#000"><br>=C2=A0 </span><span style=3D"color:#660">}</=
span><span style=3D"color:#000"><br></span><span style=3D"color:#660">}</sp=
an><span style=3D"color:#000"><br></span></div></code></div></div><br><div>=
=C2=A0</div></div></blockquote></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/3c022697-0886-493b-bda2-3648bcdacabb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3c022697-0886-493b-bda2-3648bcdacabb=
%40isocpp.org</a>.<br />

------=_Part_3141_1569879720.1468620233160--

------=_Part_3140_1977812641.1468620233160--

.

------=_Part_2165_623752907.1468612278844
Content-Type: multipart/alternative;
 boundary="----=_Part_2166_857706606.1468612278844"

------=_Part_2166_857706606.1468612278844
Content-Type: text/plain; charset=UTF-8



On Friday, July 15, 2016 at 7:22:21 PM UTC+2, Derek Hofmann wrote:
>
> Thiago,
>
> Thanks for the words of support.
>
> Thinking about this a little more, in order to mix well with old code, it
> needs a way to override the absence of the specifier or attribute in the
> way that "const_cast" and "mutable" override "const". I was thinking that
> blocks (scopes) of code within a function could be tagged as conformant
> with the specifier or attribute:
>
>     void BlockingFunc() // All functions are considered to be blocking by
> default
>     {
>     }
>
>     [[ensures(nonblocking)]] void NonblockingFunc()
>     {
>     }
>
>     [[ensures(nonblocking)]] void MyFunc()
>     {
>         BlockingFunc(); // error: "nonblocking" attribute not specified
>
>         conforms(nonblocking)
>         {
>             BlockingFunc(); // no error
>         }
>
>         NonblockingFunc(); // no error
>     }
>
>
I think you use incorrect syntax. Because "nonblocking" is attribute then
disabling it should be too.

Proper syntax should be something like that:
[[ensures(nonblocking)]] void MyFunc()
{
  int x = [[ignore(nonblocking)]] funcA();
  [[ignore(nonblocking)]]
  {
    funcB();
    funcV();
  }
}




>
> But a simple conversion cast should also work:
>
>     [[ensures(nonblocking)]] void MyFunc()
>     {
>         conform_cast<nonblocking>( BlockingFunc() ); // no error
>     }
>
> Which of the two works better, or is there a better way to mix with old
> code than either example above?
>
>     Derek
>
> On Thursday, July 14, 2016 at 5:05:27 PM UTC-7, Thiago Macieira wrote:
>>
>> On quinta-feira, 14 de julho de 2016 16:49:38 PDT Thiago Macieira wrote:
>> > > Another person had a similar idea but thought a more general solution
>> of
>> > > allowing custom type modifiers might be better:
>> > > http://allievi.sssup.it/techblog/archives/705
>> > >
>> > > Has anything like this been proposed?
>>
>> > Maybe you can widen your proposal to something like attribute
>> > [[ensures(xxx)]], which can only call other functions that have the
>> same
>> > xxx  in their [[ensures(...)]] declaration. This would allow for
>> different
>> > tags, not just "nonblocking".
>>
>> Uh... which is what you had said.
>>
>> This can also go further and be used for types, allowing the compiler to
>> complain when you mix two objects of the same type, but not of the same
>> "tag".
>> You can see an example of that in the Linux kernel, where user pointers
>> are
>> marked __user and there's some tool somewhere that checks whether you
>> made an
>> assignment you shouldn't have.
>>
>> This would also require a library function to "launder" the type and
>> erase the
>> attributes.
>>
>> --
>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>>    Software Architect - Intel Open Source Technology Center
>>
>>

--
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/c520a998-b51f-4950-b5e1-48c29701d6ad%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Friday, July 15, 2016 at 7:22:21 PM UTC+2, Dere=
k Hofmann 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"lt=
r">Thiago,<br><br>Thanks for the words of support.<br><br>Thinking about th=
is a little more, in order to mix well with old code, it needs a way to ove=
rride the absence of the specifier or attribute in the way that &quot;const=
_cast&quot; and &quot;mutable&quot; override &quot;const&quot;. I was think=
ing that blocks (scopes) of code within a function could be tagged as confo=
rmant with the specifier or attribute:<br><br><div style=3D"background-colo=
r:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;border-=
width:1px;word-wrap:break-word"><code><div><span style=3D"color:#000">=C2=
=A0 =C2=A0 </span><span style=3D"color:#008">void</span><span style=3D"colo=
r:#000"> </span><span style=3D"color:#606">BlockingFunc</span><span style=
=3D"color:#660">()</span><span style=3D"color:#000"> </span><span style=3D"=
color:#800">// All functions are considered to be </span><span style=3D"col=
or:#800">blocking by default</span><span style=3D"color:#000"><br>=C2=A0 =
=C2=A0 </span><span style=3D"color:#660">{</span><span style=3D"color:#000"=
><br>=C2=A0 =C2=A0 </span><span style=3D"color:#660">}</span><span style=3D=
"color:#000"><br><br>=C2=A0 =C2=A0 </span><span style=3D"color:#660">[[</sp=
an><span style=3D"color:#000">ensures</span><span style=3D"color:#660">(</s=
pan><span style=3D"color:#000">nonblocking</span><span style=3D"color:#660"=
>)]]</span><span style=3D"color:#000"> </span><span style=3D"color:#008">vo=
id</span><span style=3D"color:#000"> </span><span style=3D"color:#606">Nonb=
lockingFunc</span><span style=3D"color:#660">()</span><span style=3D"color:=
#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#660">{</span><span sty=
le=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#660">}</sp=
an><span style=3D"color:#000"><br><br>=C2=A0 =C2=A0 </span><span style=3D"c=
olor:#660">[[</span><span style=3D"color:#000">ensures</span><span style=3D=
"color:#660">(</span><span style=3D"color:#000">nonblocking</span><span sty=
le=3D"color:#660">)]]</span><span style=3D"color:#000"> </span><span style=
=3D"color:#008">void</span><span style=3D"color:#000"> </span><span style=
=3D"color:#606">MyFunc</span><span style=3D"color:#660">()</span><span styl=
e=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#660">{</spa=
n><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span s=
tyle=3D"color:#606">BlockingFunc</span><span style=3D"color:#660">();</span=
><span style=3D"color:#000"> </span><span style=3D"color:#800">// error: &q=
uot;nonblocking&quot; attribute not specified</span><span style=3D"color:#0=
00"><br><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 conforms</span><span style=3D"color=
:#660">(</span><span style=3D"color:#000">nonblocking</span><span style=3D"=
color:#660">)</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 </span><span style=3D"color:#660">{</span><span style=3D"color:#000"><b=
r>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#60=
6">BlockingFunc</span><span style=3D"color:#660">();</span><span style=3D"c=
olor:#000"> </span><span style=3D"color:#800">// no error</span><span style=
=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color=
:#660">}</span><span style=3D"color:#000"><br><br>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 </span><span style=3D"color:#606">NonblockingFunc</span><span style=3D"=
color:#660">();</span><span style=3D"color:#000"> </span><span style=3D"col=
or:#800">// no error</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </s=
pan><span style=3D"color:#660">}</span></div></code></div><br></div></block=
quote><div><br>I think you use incorrect syntax. Because &quot;<code><span =
style=3D"color:#660"></span><span style=3D"color:#000">nonblocking</span><s=
pan style=3D"color:#660"></span></code>&quot; is attribute then disabling i=
t should be too.<br><br>Proper syntax should be something like that:<br><di=
v class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); bord=
er-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-=
wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint=
"><span style=3D"color: #660;" class=3D"styled-by-prettify">[[</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">ensures</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">nonblocking</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">)]]</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-=
prettify">MyFunc</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">()</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r></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 </spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> x </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"col=
or: #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">ignore</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">(</span><code><span style=3D"color:#660"></span><span s=
tyle=3D"color:#000"><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">nonblocking</span></span><span style=3D"color:#660"></span></code><span =
style=3D"color: #660;" class=3D"styled-by-prettify">)]]</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> funcA</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 </span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">[[</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify">ignore</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">nonblocking</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">)]]</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br>=C2=A0 </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 funcB</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">();</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br>=C2=A0 =C2=A0 funcV</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 </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></span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></spa=
n></div></code></div><br><br>=C2=A0</div><blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div dir=3D"ltr"><br>But a simple conversion cast should also wo=
rk:<br><br><div style=3D"background-color:rgb(250,250,250);border-color:rgb=
(187,187,187);border-style:solid;border-width:1px;word-wrap:break-word"><co=
de><div><span style=3D"color:#000">=C2=A0 =C2=A0 </span><span style=3D"colo=
r:#660">[[</span><span style=3D"color:#000">ensures</span><span style=3D"co=
lor:#660">(</span><span style=3D"color:#000">nonblocking</span><span style=
=3D"color:#660">)]]</span><span style=3D"color:#000"> </span><span style=3D=
"color:#008">void</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#606">MyFunc</span><span style=3D"color:#660">()</span><span style=3D"=
color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#660">{</span><sp=
an style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 conform_cast</span>=
<span style=3D"color:#080">&lt;nonblocking&gt;</span><span style=3D"color:#=
660">(</span><span style=3D"color:#000"> </span><span style=3D"color:#606">=
BlockingFunc</span><span style=3D"color:#660">()</span><span style=3D"color=
:#000"> </span><span style=3D"color:#660">);</span><span style=3D"color:#00=
0"> </span><span style=3D"color:#800">// no error</span><span style=3D"colo=
r:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#660">}</span></div><=
/code></div><br>Which of the two works better, or is there a better way to =
mix with old code than either example above?<br><br>=C2=A0=C2=A0=C2=A0 Dere=
k<br><br>On Thursday, July 14, 2016 at 5:05:27 PM UTC-7, Thiago Macieira wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex">On quinta-feira, 14 de julho de=
 2016 16:49:38 PDT Thiago Macieira wrote:
<br>&gt; &gt; Another person had a similar idea but thought a more general =
solution of
<br>&gt; &gt; allowing custom type modifiers might be better:
<br>&gt; &gt; <a href=3D"http://allievi.sssup.it/techblog/archives/705" rel=
=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D&#39;http://www.=
google.com/url?q\x3dhttp%3A%2F%2Fallievi.sssup.it%2Ftechblog%2Farchives%2F7=
05\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFcFHW4GRe2zGcN41oQ2z28XuVmCQ&#39=
;;return true;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\x3d=
http%3A%2F%2Fallievi.sssup.it%2Ftechblog%2Farchives%2F705\x26sa\x3dD\x26snt=
z\x3d1\x26usg\x3dAFQjCNFcFHW4GRe2zGcN41oQ2z28XuVmCQ&#39;;return true;">http=
://allievi.sssup.it/<wbr>techblog/archives/705</a>
<br>&gt; &gt;=20
<br>&gt; &gt; Has anything like this been proposed?
<br>
<br>&gt; Maybe you can widen your proposal to something like attribute=20
<br>&gt; [[ensures(xxx)]], which can only call other functions that have th=
e same
<br>&gt; xxx =C2=A0in their [[ensures(...)]] declaration. This would allow =
for different
<br>&gt; tags, not just &quot;nonblocking&quot;.
<br>
<br>Uh... which is what you had said.
<br>
<br>This can also go further and be used for types, allowing the compiler t=
o=20
<br>complain when you mix two objects of the same type, but not of the same=
 &quot;tag&quot;.=20
<br>You can see an example of that in the Linux kernel, where user pointers=
 are=20
<br>marked __user and there&#39;s some tool somewhere that checks whether y=
ou made an=20
<br>assignment you shouldn&#39;t have.
<br>
<br>This would also require a library function to &quot;launder&quot; the t=
ype and erase the=20
<br>attributes.
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"n=
ofollow" target=3D"_blank" onmousedown=3D"this.href=3D&#39;http://www.googl=
e.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\x3=
dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return true;" onclick=3D"this.href=
=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3d=
D\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return tru=
e;">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" rel=3D"nofol=
low" target=3D"_blank" onmousedown=3D"this.href=3D&#39;http://www.google.co=
m/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHGR=
Jdo5_JYG1DowztwAHAKs80XSA&#39;;return true;" onclick=3D"this.href=3D&#39;ht=
tp://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x=
26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;">kde.org</a>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br></blockquote></div></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/c520a998-b51f-4950-b5e1-48c29701d6ad%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c520a998-b51f-4950-b5e1-48c29701d6ad=
%40isocpp.org</a>.<br />

------=_Part_2166_857706606.1468612278844--

------=_Part_2165_623752907.1468612278844--

.

On sexta-feira, 15 de julho de 2016 15:03:53 PDT Derek Hofmann wrote:
> That's a good catch, inkwizyt.
>
> Besides "nonblocking", another tag people might want to use is "reentrant".
> And there's already a topic about it:

Also "safe" or "untrusted".

Basically, the proposal should be for generic tags, such that the compiler
should produce a diagnostic when calling an untagged function from a tagged
one (or vice-versa), or assigning a tagged variable to an untagged one (or
vice-versa)

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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/5019810.Zmv6maglMC%40tjmaciei-mobl1.

.

On sexta-feira, 15 de julho de 2016 10:22:21 PDT Derek Hofmann wrote:
> Thinking about this a little more, in order to mix well with old code, it
> needs a way to override the absence of the specifier or attribute in the
> way that "const_cast" and "mutable" override "const". I was thinking that
> blocks (scopes) of code within a function could be tagged as conformant
> with the specifier or attribute:

That is true, but it can be done by the library function that "launders" the
attribute. You'd have to use function pointers, but it would work.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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/3345809.XmzJF0JtSQ%40tjmaciei-mobl1.

.

------=_Part_4_1023893469.1468688527367
Content-Type: multipart/alternative;
 boundary="----=_Part_5_720307015.1468688527368"

------=_Part_5_720307015.1468688527368
Content-Type: text/plain; charset=UTF-8

On Friday, July 15, 2016 at 7:45:30 PM UTC-4, Thiago Macieira wrote:
>
> On sexta-feira, 15 de julho de 2016 15:03:53 PDT Derek Hofmann wrote:
> > That's a good catch, inkwizyt.
> >
> > Besides "nonblocking", another tag people might want to use is
> "reentrant".
> > And there's already a topic about it:
>
> Also "safe" or "untrusted".
>
> Basically, the proposal should be for generic tags, such that the compiler
> should produce a diagnostic when calling an untagged function from a
> tagged
> one (or vice-versa), or assigning a tagged variable to an untagged one (or
> vice-versa)
>

I don't know. I think, conceptually speaking, there are 3 levels of
functions per-tag:

* Has the tag.
* Does not have the tag.
* Deliberately does not have the tag.

The distinction in the last two is, I think important. Consider
"nonblocking". A function can be tagged with nonblocking, and thus should
be reasonable to call from a function tagged nonblocking. But if a function
is not tagged `nonblocking`... what does that mean? Is the function
*guaranteed* to be a blocking call? Or is it just a function which wasn't
given a tag? Is it reasonable to consider `std::sqrt` to be a "blocking
call", just because it wasn't tagged appropriately?

So really, what we have is "has the tag", "has *not* the tag", and
"property unknown". And the implementer of a function should be able to
decide whether it is reasonable to call "property unknown" functions from
their tagged function.

I think it would be something like this:

[[require(tagname)]] void func1()
{
  //Can only call functions that have `tagname`
  //func1 is considered to have `tagname`
}

[[allow(tagname)]] void func2()
{
  //Cannot call functions that have `!tagname`.
  //func2 is considered to have `tagname`.
}

[[require(!tagname)]] void func3
{
  //Can only call functions that have `!tagname`.
  //func3 is considered to have `!tagname`.
}

[[allow(!tagname)]] void func4
{
  //Cannot call functions that have `tagname`
  //func4 is considered to have `!tagname`.
}

So for each tagname, a function can either have that `tagname`, have
`!tagname`, or be untagged with regard to that tag. And a function can
either allow calling `tagname` only, calling `tagname` and untagged,
calling `!tagname` only, or calling `!tagname` and untagged.

--
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/c38a4b14-964b-4603-baff-37e9f7abbebd%40isocpp.org.

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

<div dir=3D"ltr">On Friday, July 15, 2016 at 7:45:30 PM UTC-4, Thiago Macie=
ira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On sexta-feira, 15 d=
e julho de 2016 15:03:53 PDT Derek Hofmann wrote:
<br>&gt; That&#39;s a good catch, inkwizyt.
<br>&gt;=20
<br>&gt; Besides &quot;nonblocking&quot;, another tag people might want to =
use is &quot;reentrant&quot;.
<br>&gt; And there&#39;s already a topic about it:
<br>
<br>Also &quot;safe&quot; or &quot;untrusted&quot;.
<br>
<br>Basically, the proposal should be for generic tags, such that the compi=
ler=20
<br>should produce a diagnostic when calling an untagged function from a ta=
gged=20
<br>one (or vice-versa), or assigning a tagged variable to an untagged one =
(or=20
<br>vice-versa)
<br></blockquote><div><br>I don&#39;t know. I think, conceptually speaking,=
 there are 3 levels of functions per-tag:<br><br>* Has the tag.<br>* Does n=
ot have the tag.<br>* Deliberately does not have the tag.<br><br>The distin=
ction in the last two is, I think important. Consider &quot;nonblocking&quo=
t;. A function can be tagged with nonblocking, and thus should be reasonabl=
e to call from a function tagged nonblocking. But if a function is not tagg=
ed `nonblocking`... what does that mean? Is the function <i>guaranteed</i> =
to be a blocking call? Or is it just a function which wasn&#39;t given a ta=
g? Is it reasonable to consider `std::sqrt` to be a &quot;blocking call&quo=
t;, just because it wasn&#39;t tagged appropriately?<br><br>So really, what=
 we have is &quot;has the tag&quot;, &quot;has <b>not</b> the tag&quot;, an=
d &quot;property unknown&quot;. And the implementer of a function should be=
 able to decide whether it is reasonable to call &quot;property unknown&quo=
t; functions from their tagged function.<br><br>I think it would be somethi=
ng like this:<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 class=3D"prettyprint"><div=
 class=3D"subprettyprint"><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">[[</span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>require</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">tagname</sp=
an><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">void</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> func1</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">()</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>=C2=A0 </span><span style=3D"color: #800;" class=3D"styl=
ed-by-prettify">//Can only call functions that have `tagname`</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span =
style=3D"color: #800;" class=3D"styled-by-prettify">//func1 is considered t=
o have `tagname`</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br><=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">[[</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">allow</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">tagname</span><span style=3D"colo=
r: #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">void</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> func2</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br></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 </span><span style=3D"color: #800;" class=3D"styled-by-prettify">//Cann=
ot call functions that have `!tagname`.</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #800;"=
 class=3D"styled-by-prettify">//func2 is considered to have `tagname`.</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><spa=
n 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: #660;" class=3D"styled-by-prettify"><code class=3D"prettyprint">=
<span style=3D"color: #660;" class=3D"styled-by-prettify">[[</span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">require</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(!</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">tagname</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">void</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> func3<br></span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br>=C2=A0 </span><span style=3D"color: #800;" class=3D"styled-by-pret=
tify">//Can only call functions that have `!tagname`.</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D=
"color: #800;" class=3D"styled-by-prettify">//func3 is considered to have `=
!tagname`.</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></code>[[<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">allow</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">(!</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">tagname</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">)]]</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">void</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> func4<br></span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br>=C2=A0 </span><span style=3D"color: #800;" class=3D"st=
yled-by-prettify">//Cannot call functions that have `tagname`</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span =
style=3D"color: #800;" class=3D"styled-by-prettify">//func4 is considered t=
o have `!tagname`.</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></s=
pan></div></code></div><br>So for each tagname, a function can either have =
that `tagname`, have `!tagname`, or be untagged with regard to that tag. An=
d a function can either allow calling `tagname` only, calling `tagname` and=
 untagged, calling `!tagname` only, or calling `!tagname` and untagged.<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/c38a4b14-964b-4603-baff-37e9f7abbebd%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c38a4b14-964b-4603-baff-37e9f7abbebd=
%40isocpp.org</a>.<br />

------=_Part_5_720307015.1468688527368--

------=_Part_4_1023893469.1468688527367--

.

On s=C3=A1bado, 16 de julho de 2016 10:02:07 PDT Nicol Bolas wrote:
> The distinction in the last two is, I think important. Consider=20
> "nonblocking". A function can be tagged with nonblocking, and thus should=
=20
> be reasonable to call from a function tagged nonblocking. But if a functi=
on=20
> is not tagged `nonblocking`... what does that mean? Is the function
> *guaranteed* to be a blocking call? Or is it just a function which wasn't
> given a tag? Is it reasonable to consider `std::sqrt` to be a "blocking
> call", just because it wasn't tagged appropriately?

And then there are the functions that may block, given some arguments.

For example, all the waitForXxx functions in Qt with a timeout: if the time=
out=20
is zero, they don't block.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=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/4650306.XdD0mYVgqf%40tjmaciei-mobl1.

.

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

For me, I'm mainly concerned about whether a function is guaranteed safe
(nonblocking) or not guaranteed safe. Being able to distinguish between two
substates of "not guaranteed safe" (unknown vs. guaranteed unsafe) adds a
little value but a lot of complexity to the specification.

What's a situation where 3 levels per tag is needed?

On Jul 16, 2016 10:02 AM, "Nicol Bolas" <jmckesson@gmail.com> wrote:

> On Friday, July 15, 2016 at 7:45:30 PM UTC-4, Thiago Macieira wrote:
>>
>> On sexta-feira, 15 de julho de 2016 15:03:53 PDT Derek Hofmann wrote:
>> > That's a good catch, inkwizyt.
>> >
>> > Besides "nonblocking", another tag people might want to use is
>> "reentrant".
>> > And there's already a topic about it:
>>
>> Also "safe" or "untrusted".
>>
>> Basically, the proposal should be for generic tags, such that the
>> compiler
>> should produce a diagnostic when calling an untagged function from a
>> tagged
>> one (or vice-versa), or assigning a tagged variable to an untagged one
>> (or
>> vice-versa)
>>
>
> I don't know. I think, conceptually speaking, there are 3 levels of
> functions per-tag:
>
> * Has the tag.
> * Does not have the tag.
> * Deliberately does not have the tag.
>
> The distinction in the last two is, I think important. Consider
> "nonblocking". A function can be tagged with nonblocking, and thus should
> be reasonable to call from a function tagged nonblocking. But if a function
> is not tagged `nonblocking`... what does that mean? Is the function
> *guaranteed* to be a blocking call? Or is it just a function which wasn't
> given a tag? Is it reasonable to consider `std::sqrt` to be a "blocking
> call", just because it wasn't tagged appropriately?
>
> So really, what we have is "has the tag", "has *not* the tag", and
> "property unknown". And the implementer of a function should be able to
> decide whether it is reasonable to call "property unknown" functions from
> their tagged function.
>
> I think it would be something like this:
>
> [[require(tagname)]] void func1()
> {
>   //Can only call functions that have `tagname`
>   //func1 is considered to have `tagname`
> }
>
> [[allow(tagname)]] void func2()
> {
>   //Cannot call functions that have `!tagname`.
>   //func2 is considered to have `tagname`.
> }
>
> [[require(!tagname)]] void func3
> {
>   //Can only call functions that have `!tagname`.
>   //func3 is considered to have `!tagname`.
> }
>
> [[allow(!tagname)]] void func4
> {
>   //Cannot call functions that have `tagname`
>   //func4 is considered to have `!tagname`.
> }
>
> So for each tagname, a function can either have that `tagname`, have
> `!tagname`, or be untagged with regard to that tag. And a function can
> either allow calling `tagname` only, calling `tagname` and untagged,
> calling `!tagname` only, or calling `!tagname` and untagged.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/q8bMB4ZTl4E/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/c38a4b14-964b-4603-baff-37e9f7abbebd%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c38a4b14-964b-4603-baff-37e9f7abbebd%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/CAK%2BHGD7Eu8V8qTsdOHirs2XSVztN2gazUgEC%2BA6vekeK2XkVxg%40mail.gmail.com.

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

<p dir=3D"ltr">For me, I&#39;m mainly concerned about whether a function is=
 guaranteed safe (nonblocking) or not guaranteed safe. Being able to distin=
guish between two substates of &quot;not guaranteed safe&quot; (unknown vs.=
 guaranteed unsafe) adds a little value but a lot of complexity to the spec=
ification.</p>
<p dir=3D"ltr">What&#39;s a situation where 3 levels per tag is needed?</p>
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Jul 16, 2016 1=
0:02 AM, &quot;Nicol Bolas&quot; &lt;<a href=3D"mailto:jmckesson@gmail.com"=
>jmckesson@gmail.com</a>&gt; wrote:<br type=3D"attribution"><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr">On Friday, July 15, 2016 at 7:45:30 PM UTC=
-4, Thiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On sexta-=
feira, 15 de julho de 2016 15:03:53 PDT Derek Hofmann wrote:
<br>&gt; That&#39;s a good catch, inkwizyt.
<br>&gt;=20
<br>&gt; Besides &quot;nonblocking&quot;, another tag people might want to =
use is &quot;reentrant&quot;.
<br>&gt; And there&#39;s already a topic about it:
<br>
<br>Also &quot;safe&quot; or &quot;untrusted&quot;.
<br>
<br>Basically, the proposal should be for generic tags, such that the compi=
ler=20
<br>should produce a diagnostic when calling an untagged function from a ta=
gged=20
<br>one (or vice-versa), or assigning a tagged variable to an untagged one =
(or=20
<br>vice-versa)
<br></blockquote><div><br>I don&#39;t know. I think, conceptually speaking,=
 there are 3 levels of functions per-tag:<br><br>* Has the tag.<br>* Does n=
ot have the tag.<br>* Deliberately does not have the tag.<br><br>The distin=
ction in the last two is, I think important. Consider &quot;nonblocking&quo=
t;. A function can be tagged with nonblocking, and thus should be reasonabl=
e to call from a function tagged nonblocking. But if a function is not tagg=
ed `nonblocking`... what does that mean? Is the function <i>guaranteed</i> =
to be a blocking call? Or is it just a function which wasn&#39;t given a ta=
g? Is it reasonable to consider `std::sqrt` to be a &quot;blocking call&quo=
t;, just because it wasn&#39;t tagged appropriately?<br><br>So really, what=
 we have is &quot;has the tag&quot;, &quot;has <b>not</b> the tag&quot;, an=
d &quot;property unknown&quot;. And the implementer of a function should be=
 able to decide whether it is reasonable to call &quot;property unknown&quo=
t; functions from their tagged function.<br><br>I think it would be somethi=
ng like this:<br><br><div 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><div><span style=3D"color:#660">[[</span><span style=3D"color:=
#008">require</span><span style=3D"color:#660">(</span><span style=3D"color=
:#000">tagname</span><span style=3D"color:#660">)]]</span><span style=3D"co=
lor:#000"> </span><span style=3D"color:#008">void</span><span style=3D"colo=
r:#000"> func1</span><span style=3D"color:#660">()</span><span style=3D"col=
or:#000"><br></span><span style=3D"color:#660">{</span><span style=3D"color=
:#000"><br>=C2=A0 </span><span style=3D"color:#800">//Can only call functio=
ns that have `tagname`</span><span style=3D"color:#000"><br>=C2=A0 </span><=
span style=3D"color:#800">//func1 is considered to have `tagname`</span><sp=
an style=3D"color:#000"><br></span><span style=3D"color:#660">}</span><span=
 style=3D"color:#000"><br><br></span><span style=3D"color:#660">[[</span><s=
pan style=3D"color:#000">allow</span><span style=3D"color:#660">(</span><sp=
an style=3D"color:#000">tagname</span><span style=3D"color:#660">)]]</span>=
<span style=3D"color:#000"> </span><span style=3D"color:#008">void</span><s=
pan style=3D"color:#000"> func2</span><span style=3D"color:#660">()</span><=
span style=3D"color:#000"><br></span><span style=3D"color:#660">{</span><sp=
an style=3D"color:#000"><br>=C2=A0 </span><span style=3D"color:#800">//Cann=
ot call functions that have `!tagname`.</span><span style=3D"color:#000"><b=
r>=C2=A0 </span><span style=3D"color:#800">//func2 is considered to have `t=
agname`.</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=
:#660"><code><span style=3D"color:#660">[[</span><span style=3D"color:#008"=
>require</span><span style=3D"color:#660">(!</span><span style=3D"color:#00=
0">tagname</span><span style=3D"color:#660">)]]</span><span style=3D"color:=
#000"> </span><span style=3D"color:#008">void</span><span style=3D"color:#0=
00"> func3<br></span><span style=3D"color:#660">{</span><span style=3D"colo=
r:#000"><br>=C2=A0 </span><span style=3D"color:#800">//Can only call functi=
ons that have `!tagname`.</span><span style=3D"color:#000"><br>=C2=A0 </spa=
n><span style=3D"color:#800">//func3 is considered to have `!tagname`.</spa=
n><span style=3D"color:#000"><br></span><span style=3D"color:#660">}</span>=
<span style=3D"color:#000"><br></span><span style=3D"color:#000"><br></span=
></code>[[</span><span style=3D"color:#000">allow</span><span style=3D"colo=
r:#660">(!</span><span style=3D"color:#000">tagname</span><span style=3D"co=
lor:#660">)]]</span><span style=3D"color:#000"> </span><span style=3D"color=
:#008">void</span><span style=3D"color:#000"> func4<br></span><span style=
=3D"color:#660">{</span><span style=3D"color:#000"><br>=C2=A0 </span><span =
style=3D"color:#800">//Cannot call functions that have `tagname`</span><spa=
n style=3D"color:#000"><br>=C2=A0 </span><span style=3D"color:#800">//func4=
 is considered to have `!tagname`.</span><span style=3D"color:#000"><br></s=
pan><span style=3D"color:#660">}</span><span style=3D"color:#000"><br></spa=
n></div></code></div><br>So for each tagname, a function can either have th=
at `tagname`, have `!tagname`, or be untagged with regard to that tag. And =
a function can either allow calling `tagname` only, calling `tagname` and u=
ntagged, calling `!tagname` only, or calling `!tagname` and untagged.<br></=
div></div>

<p></p>

-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/q8bMB4ZTl4E/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/q8bMB4ZTl4E=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+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/c38a4b14-964b-4603-baff-37e9f7abbebd%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c38a4b14-964b-=
4603-baff-37e9f7abbebd%40isocpp.org</a>.<br>
</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/CAK%2BHGD7Eu8V8qTsdOHirs2XSVztN2gazUg=
EC%2BA6vekeK2XkVxg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAK%2BHGD7Eu8=
V8qTsdOHirs2XSVztN2gazUgEC%2BA6vekeK2XkVxg%40mail.gmail.com</a>.<br />

--001a113cdc4a64d6af0537c71038--

.

------=_Part_98_1921327477.1468714397096
Content-Type: multipart/alternative;
 boundary="----=_Part_99_1554901870.1468714397096"

------=_Part_99_1554901870.1468714397096
Content-Type: text/plain; charset=UTF-8

On Saturday, July 16, 2016 at 5:03:18 PM UTC-4, Derek Hofmann wrote:
>
> For me, I'm mainly concerned about whether a function is guaranteed safe
> (nonblocking) or not guaranteed safe. Being able to distinguish between two
> substates of "not guaranteed safe" (unknown vs. guaranteed unsafe) adds a
> little value but a lot of complexity to the specification.
>
> What's a situation where 3 levels per tag is needed?
>

Pretty much any time you try to break into the world of code that you
didn't write and don't have control over.

For your blocking example, there's no reason to consider, for instance,
`sqrt` to be a blocking call. But it doesn't have an appropriate tag in it.
There are many function in `vector` which don't allocate memory, yet they
aren't tagged nonblocking either. And so forth.

Really, for something like "blocking", I would much rather annotate the
functions that are *known* to be blocking and then declare functions that
aren't allowed to call blocking functions.

Also, what about templates? A function like `sort` could be blocking or
nonblocking, depending on what the function it is given does. How would
that work?

--
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/f015af6e-abe5-4d27-92bd-6cb929648d6b%40isocpp.org.

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

<div dir=3D"ltr">On Saturday, July 16, 2016 at 5:03:18 PM UTC-4, Derek Hofm=
ann wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><p dir=3D"ltr">For m=
e, I&#39;m mainly concerned about whether a function is guaranteed safe (no=
nblocking) or not guaranteed safe. Being able to distinguish between two su=
bstates of &quot;not guaranteed safe&quot; (unknown vs. guaranteed unsafe) =
adds a little value but a lot of complexity to the specification.</p>
<p dir=3D"ltr">What&#39;s a situation where 3 levels per tag is needed?</p>=
</blockquote><div><br>Pretty much any time you try to break into the world =
of code that you didn&#39;t write and don&#39;t have control over.<br><br>F=
or your blocking example, there&#39;s no reason to consider, for instance, =
`sqrt` to be a blocking call. But it doesn&#39;t have an appropriate tag in=
 it. There are many function in `vector` which don&#39;t allocate memory, y=
et they aren&#39;t tagged nonblocking either. And so forth.<br><br>Really, =
for something like &quot;blocking&quot;, I would much rather annotate the f=
unctions that are <i>known</i> to be blocking and then declare functions th=
at aren&#39;t allowed to call blocking functions.<br><br>Also, what about t=
emplates? A function like `sort` could be blocking or nonblocking, dependin=
g on what the function it is given does. How would that work?<br></div></di=
v>

<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/f015af6e-abe5-4d27-92bd-6cb929648d6b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f015af6e-abe5-4d27-92bd-6cb929648d6b=
%40isocpp.org</a>.<br />

------=_Part_99_1554901870.1468714397096--

------=_Part_98_1921327477.1468714397096--

.

On Sat, Jul 16, 2016 at 10:02:07AM -0700, Nicol Bolas wrote:
> On Friday, July 15, 2016 at 7:45:30 PM UTC-4, Thiago Macieira wrote:
> >
> > On sexta-feira, 15 de julho de 2016 15:03:53 PDT Derek Hofmann wrote:
> > > That's a good catch, inkwizyt.
> > >
> > > Besides "nonblocking", another tag people might want to use is
> > "reentrant".
> > > And there's already a topic about it:
> >
> > Also "safe" or "untrusted".
> >
> > Basically, the proposal should be for generic tags, such that the compiler
> > should produce a diagnostic when calling an untagged function from a
> > tagged
> > one (or vice-versa), or assigning a tagged variable to an untagged one (or
> > vice-versa)
> >
>
> I don't know. I think, conceptually speaking, there are 3 levels of
> functions per-tag:
>
> * Has the tag.
> * Does not have the tag.
> * Deliberately does not have the tag.
>
> The distinction in the last two is, I think important. Consider
> "nonblocking". A function can be tagged with nonblocking, and thus should
> be reasonable to call from a function tagged nonblocking. But if a function
> is not tagged `nonblocking`... what does that mean? Is the function
> *guaranteed* to be a blocking call? Or is it just a function which wasn't
> given a tag? Is it reasonable to consider `std::sqrt` to be a "blocking
> call", just because it wasn't tagged appropriately?
>
> So really, what we have is "has the tag", "has *not* the tag", and
> "property unknown". And the implementer of a function should be able to
> decide whether it is reasonable to call "property unknown" functions from
> their tagged function.
>
> I think it would be something like this:
>
> [[require(tagname)]] void func1()
> {
>   //Can only call functions that have `tagname`
>   //func1 is considered to have `tagname`
> }
>
> [[allow(tagname)]] void func2()
> {
>   //Cannot call functions that have `!tagname`.
>   //func2 is considered to have `tagname`.
> }
>
> [[require(!tagname)]] void func3
> {
>   //Can only call functions that have `!tagname`.
>   //func3 is considered to have `!tagname`.
> }
>
> [[allow(!tagname)]] void func4
> {
>   //Cannot call functions that have `tagname`
>   //func4 is considered to have `!tagname`.
> }
>
> So for each tagname, a function can either have that `tagname`, have
> `!tagname`, or be untagged with regard to that tag. And a function can
> either allow calling `tagname` only, calling `tagname` and untagged,
> calling `!tagname` only, or calling `!tagname` and untagged.

When I read this thread I see a lot of similarites with exception specifiers
and I am wondering if there is a need for tagged blocks for this as well,
something along the lines of

[[require(tagname)]] void func1()
{
 ...
 [[promise(tagname)]] { // The programmer promises that the calls in
          // this block fulfils the requirements of
          // tagname even if they are !tagname
  func3();
 }
 ...
}

where this is inspired by the try-blocks of exception specifications.

/MF

--
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/20160717053639.GA3436%40noemi.

.

------=_Part_54_32477845.1468796644069
Content-Type: multipart/alternative;
 boundary="----=_Part_55_1310256284.1468796644069"

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

On Thursday, July 14, 2016 at 5:05:27 PM UTC-7, Thiago Macieira wrote:
>
> On quinta-feira, 14 de julho de 2016 16:49:38 PDT Thiago Macieira wrote:=
=20
> > > Another person had a similar idea but thought a more general solution=
=20
> of=20
> > > allowing custom type modifiers might be better:=20
> > > http://allievi.sssup.it/techblog/archives/705=20
> > >=20
> > > Has anything like this been proposed?=20
>
> > Maybe you can widen your proposal to something like attribute=20
> > [[ensures(xxx)]], which can only call other functions that have the sam=
e=20
> > xxx  in their [[ensures(...)]] declaration. This would allow for=20
> different=20
> > tags, not just "nonblocking".=20
>
> Uh... which is what you had said.=20
>

Not only has this idea been proposed, it has an implementation (for C) in=
=20
the research project "CQUAL", circa 2002.
http://www.cs.umd.edu/~jfoster/cqual/
The idea is to permit arbitrary additions to the set of cv-qualifiers, with=
=20
the usual rules about which cv-qualifiers are allowed to be implicitly=20
added or dropped to which kinds of expressions.  For example:
- A "string [[untrusted]] &" cannot be converted to a "string&" except=20
through a laundering function (such as const_cast).
- A member function qualified with "[[nonblocking]]" implicitly adds the=20
[[nonblocking]] qualifier to its "this" object, so it can't call=20
non-[[nonblocking]] methods on that object (without laundering, that is).
- An arbitrary "char *" cannot be passed to a function that expects a "char=
=20
[[kernelspace]] *" (without laundering, that is).

CQUAL's type-qualifier-based approach probably isn't 100% what Derek wants,=
=20
because it applies only to objects, not to control flow (i.e. my bullet=20
point above about [[nonblocking]] explicitly doesn't say that you're only=
=20
allowed to call [[nonblocking]] functions; it says you're only allowed to=
=20
call [[nonblocking]] *methods* on the this object).  However, I think you=
=20
could work around this in practice, if the feature were valuable enough to=
=20
you, by passing a cv-qualified "context" object to all your non-OOP=20
functions:

    void frotz(context *ctx, int value);  // blocking by default

    void frobnicate([[nonblocking]] context *ctx, Some&& arguments)
    {
        frotz(ctx, 42);  // overload resolution fails because=20
([[nonblocking]] context *) isn't implicitly convertible to (context *)
    }

Mind you, if you cared that much, you'd probably be doing the above=20
already, using custom tag types.  The GSL's "not_null<T*>" is an example of=
=20
that approach: (not_null<T *>) is implicitly convertible to (T *) but not=
=20
vice versa.

Given that you can already do this with GSL-style tag types, and I don't=20
think the CQUAL-style approach would actually result in much less typing=20
(just more complication to the type system), my thinking right now is that=
=20
there's not a compelling reason to pursue the CQUAL-style approach at the=
=20
moment.

Derek, have you tried the GSL/not_null-style approach in a real codebase?=
=20
 If so, how did it do?

=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/44f5d65c-8c10-449b-baf1-ec71c815e099%40isocpp.or=
g.

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

<div dir=3D"ltr">On Thursday, July 14, 2016 at 5:05:27 PM UTC-7, Thiago Mac=
ieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On quinta-feira, 1=
4 de julho de 2016 16:49:38 PDT Thiago Macieira wrote:
<br>&gt; &gt; Another person had a similar idea but thought a more general =
solution of
<br>&gt; &gt; allowing custom type modifiers might be better:
<br>&gt; &gt; <a href=3D"http://allievi.sssup.it/techblog/archives/705" tar=
get=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.=
google.com/url?q\x3dhttp%3A%2F%2Fallievi.sssup.it%2Ftechblog%2Farchives%2F7=
05\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFcFHW4GRe2zGcN41oQ2z28XuVmCQ&#39=
;;return true;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\x3d=
http%3A%2F%2Fallievi.sssup.it%2Ftechblog%2Farchives%2F705\x26sa\x3dD\x26snt=
z\x3d1\x26usg\x3dAFQjCNFcFHW4GRe2zGcN41oQ2z28XuVmCQ&#39;;return true;">http=
://allievi.sssup.it/<wbr>techblog/archives/705</a>
<br>&gt; &gt;=20
<br>&gt; &gt; Has anything like this been proposed?
<br>
<br>&gt; Maybe you can widen your proposal to something like attribute=20
<br>&gt; [[ensures(xxx)]], which can only call other functions that have th=
e same
<br>&gt; xxx =C2=A0in their [[ensures(...)]] declaration. This would allow =
for different
<br>&gt; tags, not just &quot;nonblocking&quot;.
<br>
<br>Uh... which is what you had said.
<br></blockquote><div><br></div><div>Not only has this idea been proposed, =
it has an implementation (for C) in the research project &quot;CQUAL&quot;,=
 circa 2002.</div><div>http://www.cs.umd.edu/~jfoster/cqual/<br></div><div>=
The idea is to permit arbitrary additions to the set of cv-qualifiers, with=
 the usual rules about which cv-qualifiers are allowed to be implicitly add=
ed or dropped to which kinds of expressions. =C2=A0For example:</div><div>-=
 A &quot;string [[untrusted]] &amp;&quot; cannot be converted to a &quot;st=
ring&amp;&quot; except through a laundering function (such as const_cast).<=
/div><div>- A member function qualified with &quot;[[nonblocking]]&quot; im=
plicitly adds the [[nonblocking]] qualifier to its &quot;this&quot; object,=
 so it can&#39;t call non-[[nonblocking]] methods on that object (without l=
aundering, that is).</div><div>- An arbitrary &quot;char *&quot; cannot be =
passed to a function that expects a &quot;char [[kernelspace]] *&quot; (wit=
hout laundering, that is).</div><div><br></div><div>CQUAL&#39;s type-qualif=
ier-based approach probably isn&#39;t 100% what Derek wants, because it app=
lies only to objects, not to control flow (i.e. my bullet point above about=
 [[nonblocking]] explicitly doesn&#39;t say that you&#39;re only allowed to=
 call [[nonblocking]] functions; it says you&#39;re only allowed to call [[=
nonblocking]] <i>methods</i> on the this object). =C2=A0However, I think yo=
u could work around this in practice, if the feature were valuable enough t=
o you, by passing a cv-qualified &quot;context&quot; object to all your non=
-OOP functions:</div><div><br></div><div>=C2=A0 =C2=A0 void frotz(context *=
ctx, int value); =C2=A0// blocking by default</div><div><br></div><div>=C2=
=A0 =C2=A0 void frobnicate([[nonblocking]] context *ctx, Some&amp;&amp; arg=
uments)</div><div>=C2=A0 =C2=A0 {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 fro=
tz(ctx, 42); =C2=A0// overload resolution fails because ([[nonblocking]] co=
ntext *) isn&#39;t implicitly convertible to (context *)</div><div>=C2=A0 =
=C2=A0 }</div><div><br></div><div>Mind you, if you cared that much, you&#39=
;d probably be doing the above already, using custom tag types. =C2=A0The G=
SL&#39;s &quot;not_null&lt;T*&gt;&quot; is an example of that approach: (no=
t_null&lt;T *&gt;) is implicitly convertible to (T *) but not vice versa.</=
div><div><br></div><div>Given that you can already do this with GSL-style t=
ag types, and I don&#39;t think the CQUAL-style approach would actually res=
ult in much less typing (just more complication to the type system), my thi=
nking right now is that there&#39;s not a compelling reason to pursue the C=
QUAL-style approach at the moment.</div><div><br></div><div>Derek, have you=
 tried the GSL/not_null-style approach in a real codebase? =C2=A0If so, how=
 did it do?</div><div><br></div><div>=E2=80=93Arthur</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/44f5d65c-8c10-449b-baf1-ec71c815e099%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/44f5d65c-8c10-449b-baf1-ec71c815e099=
%40isocpp.org</a>.<br />

------=_Part_55_1310256284.1468796644069--

------=_Part_54_32477845.1468796644069--

.

--94eb2c06623a4f0a520537dd8672
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

This seems very similar, in principle, to Boost.Units.
Could it not be implemented similarly, in current existing C++14?

On Sun, Jul 17, 2016 at 7:04 PM, Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
wrote:

> On Thursday, July 14, 2016 at 5:05:27 PM UTC-7, Thiago Macieira wrote:
>>
>> On quinta-feira, 14 de julho de 2016 16:49:38 PDT Thiago Macieira wrote:
>> > > Another person had a similar idea but thought a more general solutio=
n
>> of
>> > > allowing custom type modifiers might be better:
>> > > http://allievi.sssup.it/techblog/archives/705
>> > >
>> > > Has anything like this been proposed?
>>
>> > Maybe you can widen your proposal to something like attribute
>> > [[ensures(xxx)]], which can only call other functions that have the
>> same
>> > xxx  in their [[ensures(...)]] declaration. This would allow for
>> different
>> > tags, not just "nonblocking".
>>
>> Uh... which is what you had said.
>>
>
> Not only has this idea been proposed, it has an implementation (for C) in
> the research project "CQUAL", circa 2002.
> http://www.cs.umd.edu/~jfoster/cqual/
> The idea is to permit arbitrary additions to the set of cv-qualifiers,
> with the usual rules about which cv-qualifiers are allowed to be implicit=
ly
> added or dropped to which kinds of expressions.  For example:
> - A "string [[untrusted]] &" cannot be converted to a "string&" except
> through a laundering function (such as const_cast).
> - A member function qualified with "[[nonblocking]]" implicitly adds the
> [[nonblocking]] qualifier to its "this" object, so it can't call
> non-[[nonblocking]] methods on that object (without laundering, that is).
> - An arbitrary "char *" cannot be passed to a function that expects a
> "char [[kernelspace]] *" (without laundering, that is).
>
> CQUAL's type-qualifier-based approach probably isn't 100% what Derek
> wants, because it applies only to objects, not to control flow (i.e. my
> bullet point above about [[nonblocking]] explicitly doesn't say that you'=
re
> only allowed to call [[nonblocking]] functions; it says you're only allow=
ed
> to call [[nonblocking]] *methods* on the this object).  However, I think
> you could work around this in practice, if the feature were valuable enou=
gh
> to you, by passing a cv-qualified "context" object to all your non-OOP
> functions:
>
>     void frotz(context *ctx, int value);  // blocking by default
>
>     void frobnicate([[nonblocking]] context *ctx, Some&& arguments)
>     {
>         frotz(ctx, 42);  // overload resolution fails because
> ([[nonblocking]] context *) isn't implicitly convertible to (context *)
>     }
>
> Mind you, if you cared that much, you'd probably be doing the above
> already, using custom tag types.  The GSL's "not_null<T*>" is an example =
of
> that approach: (not_null<T *>) is implicitly convertible to (T *) but not
> vice versa.
>
> Given that you can already do this with GSL-style tag types, and I don't
> think the CQUAL-style approach would actually result in much less typing
> (just more complication to the type system), my thinking right now is tha=
t
> there's not a compelling reason to pursue the CQUAL-style approach at the
> moment.
>
> Derek, have you tried the GSL/not_null-style approach in a real codebase?
> If so, how did it do?
>
> =E2=80=93Arthur
>
> --
> 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/44f5d65c-8c1=
0-449b-baf1-ec71c815e099%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/44f5d65c-8c=
10-449b-baf1-ec71c815e099%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>

--=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/CAMD6iD8n3M29tvnJEsJ1JZEZa6QgBznaZDys-67dCL4wb7R=
twQ%40mail.gmail.com.

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

<div dir=3D"ltr">This seems very similar, in principle, to Boost.Units.<div=
>Could it not be implemented similarly, in current existing C++14?</div></d=
iv><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sun, Jul 17=
, 2016 at 7:04 PM, Arthur O&#39;Dwyer <span dir=3D"ltr">&lt;<a href=3D"mail=
to:arthur.j.odwyer@gmail.com" target=3D"_blank">arthur.j.odwyer@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"><sp=
an class=3D"">On Thursday, July 14, 2016 at 5:05:27 PM UTC-7, Thiago Maciei=
ra wrote:</span><span class=3D""><blockquote class=3D"gmail_quote" style=3D=
"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On=
 quinta-feira, 14 de julho de 2016 16:49:38 PDT Thiago Macieira wrote:
<br>&gt; &gt; Another person had a similar idea but thought a more general =
solution of
<br>&gt; &gt; allowing custom type modifiers might be better:
<br>&gt; &gt; <a href=3D"http://allievi.sssup.it/techblog/archives/705" rel=
=3D"nofollow" target=3D"_blank">http://allievi.sssup.it/techblog/archives/7=
05</a>
<br>&gt; &gt;=20
<br>&gt; &gt; Has anything like this been proposed?
<br>
<br>&gt; Maybe you can widen your proposal to something like attribute=20
<br>&gt; [[ensures(xxx)]], which can only call other functions that have th=
e same
<br>&gt; xxx =C2=A0in their [[ensures(...)]] declaration. This would allow =
for different
<br>&gt; tags, not just &quot;nonblocking&quot;.
<br>
<br>Uh... which is what you had said.
<br></blockquote><div><br></div></span><div>Not only has this idea been pro=
posed, it has an implementation (for C) in the research project &quot;CQUAL=
&quot;, circa 2002.</div><div><a href=3D"http://www.cs.umd.edu/~jfoster/cqu=
al/" target=3D"_blank">http://www.cs.umd.edu/~jfoster/cqual/</a><br></div><=
div>The idea is to permit arbitrary additions to the set of cv-qualifiers, =
with the usual rules about which cv-qualifiers are allowed to be implicitly=
 added or dropped to which kinds of expressions.=C2=A0 For example:</div><d=
iv>- A &quot;string [[untrusted]] &amp;&quot; cannot be converted to a &quo=
t;string&amp;&quot; except through a laundering function (such as const_cas=
t).</div><div>- A member function qualified with &quot;[[nonblocking]]&quot=
; implicitly adds the [[nonblocking]] qualifier to its &quot;this&quot; obj=
ect, so it can&#39;t call non-[[nonblocking]] methods on that object (witho=
ut laundering, that is).</div><div>- An arbitrary &quot;char *&quot; cannot=
 be passed to a function that expects a &quot;char [[kernelspace]] *&quot; =
(without laundering, that is).</div><div><br></div><div>CQUAL&#39;s type-qu=
alifier-based approach probably isn&#39;t 100% what Derek wants, because it=
 applies only to objects, not to control flow (i.e. my bullet point above a=
bout [[nonblocking]] explicitly doesn&#39;t say that you&#39;re only allowe=
d to call [[nonblocking]] functions; it says you&#39;re only allowed to cal=
l [[nonblocking]] <i>methods</i> on the this object).=C2=A0 However, I thin=
k you could work around this in practice, if the feature were valuable enou=
gh to you, by passing a cv-qualified &quot;context&quot; object to all your=
 non-OOP functions:</div><div><br></div><div>=C2=A0 =C2=A0 void frotz(conte=
xt *ctx, int value); =C2=A0// blocking by default</div><div><br></div><div>=
=C2=A0 =C2=A0 void frobnicate([[nonblocking]] context *ctx, Some&amp;&amp; =
arguments)</div><div>=C2=A0 =C2=A0 {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
frotz(ctx, 42); =C2=A0// overload resolution fails because ([[nonblocking]]=
 context *) isn&#39;t implicitly convertible to (context *)</div><div>=C2=
=A0 =C2=A0 }</div><div><br></div><div>Mind you, if you cared that much, you=
&#39;d probably be doing the above already, using custom tag types.=C2=A0 T=
he GSL&#39;s &quot;not_null&lt;T*&gt;&quot; is an example of that approach:=
 (not_null&lt;T *&gt;) is implicitly convertible to (T *) but not vice vers=
a.</div><div><br></div><div>Given that you can already do this with GSL-sty=
le tag types, and I don&#39;t think the CQUAL-style approach would actually=
 result in much less typing (just more complication to the type system), my=
 thinking right now is that there&#39;s not a compelling reason to pursue t=
he CQUAL-style approach at the moment.</div><div><br></div><div>Derek, have=
 you tried the GSL/not_null-style approach in a real codebase?=C2=A0 If so,=
 how did it do?</div><div><br></div><div>=E2=80=93Arthur</div></div><span c=
lass=3D"">

<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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/44f5d65c-8c10-449b-baf1-ec71c815e099%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/44f5d65c-8c10-=
449b-baf1-ec71c815e099%40isocpp.org</a>.<br>
</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/CAMD6iD8n3M29tvnJEsJ1JZEZa6QgBznaZDys=
-67dCL4wb7RtwQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD8n3M29tvnJ=
EsJ1JZEZa6QgBznaZDys-67dCL4wb7RtwQ%40mail.gmail.com</a>.<br />

--94eb2c06623a4f0a520537dd8672--

.

On 07/16/2016 01:45 AM, Thiago Macieira wrote:
> On sexta-feira, 15 de julho de 2016 15:03:53 PDT Derek Hofmann wrote:

>> Besides "nonblocking", another tag people might want to use is "reentrant".
>> And there's already a topic about it:
>
> Also "safe" or "untrusted".

Or signal-safe as added by P0270R0.

--
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/579387E0.4090009%40mail1.stofanet.dk.

.