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

I have been wondering this question several times through reading the
different proposals
about assertions and more generally the last paper N4160 analysing value
constraints.
Here is an excerpt from it:

"One thing that appears non-controversial is that declarations of
preconditions and postconditions need to be part of function declaration,
so that they are accessible by the function users who may not have access
to function definitions. We leave it open whether a value constraint
declaration should affect function's signature or type or affect the
overload resolution mechanism; although it looks like affecting function's
type would make it impossible to retrofit value constraints into the
existing code."

First, I understand that it might feels "natural" to initially consider
post/pre-conditions as part of the
signature. However:

 1. I didn't see any proposal even trying to explore the actual properties
that would have a grammar allowing (not forcing) to have
pre/post-conditions expressed separately. And as explained in the following
example, I don't see major issues if...
 2. ...we assume that such value constrain feature will certainly have one
or several ways
    to chose the actual effect (ignored, statically checked, runtime
checked, other...)
     by either the library user or the library designer or both.
     In this case, having a way to provide constraints as an optional
separate set of
     information about the types would seem reasonable to me.

It seems to me that pre/post-conditions could be considered the same way
free functions
manipulating a data type would be separate but still augmenting optionally
the possibilities
offered by that data type.

From N4160:

"Another concern that we have is that if we combine all kinds of possible
function contract, like concepts, value constraints, conditions on these
constraints, the declarations could become unbearably long. Reconsider the
example of std::find from above. In order to make it short, we made it
incorrect. The postcondition cannot be defined for non-ForwardIterator
types. If we tried to really constrain std::find, (using some invented
syntax and assuming Concepts Lite, and the new Range design being proposed
(see [N4128])) it would go:

template<InputIterator I, Regular S, Regular V>
  requires EqualityComparable<I, S> && EqualityComparable<Value_type<I>, V>
I find(I b, S e, const V& v)
precondition{ is_valid_range(b, e); }
postcondition(f) {
  is_valid_range(b, f)
    requires ForwardIterator<I>;
  is_valid_range(f, e);
  [[contract::never_evaluate]]
  none_of(b, f, [](const Value_type<I>& x){x == v})
    requires ForwardIterator<I>;
  [[contract::complexity(constant)]]
  f == e || *f == v
    requires ForwardIterator<I>;
};
Does this declaration not look scary?"

Taking the concerning example and trying to imagine such a separation, I
end-up
with this:


// Header containing find()

template<InputIterator I, Regular S, Regular V>
  requires EqualityComparable<I, S> && EqualityComparable<Value_type<I>, V>
I find(I b, S e, const V& v);

// Header containing constraints for find()
// Optionally implicitely included by the previous header

template<InputIterator I, Regular S, Regular V>
precondition I find(I b, S e, const V& v)
{
    is_valid_range(b, e);
}

template<InputIterator I, Regular S, Regular V>
postcondition(f) I find(I b, S e, const V& v)
{
  is_valid_range(b, f);
  is_valid_range(f, e);
  f == e || *f == v;
}

template<InputIterator I, Regular S, Regular V>
postcondition(f) I find(I b, S e, const V& v)
    requires ForwardIterator<I>;
{
  is_valid_range(b, f)
  is_valid_range(f, e);
  none_of(b, f, [](const Value_type<I>& x){x == v});
  f == e || *f == v;
}


Assume that this way of expressing the example have the exact same meaning
as before.
The main difference is that having the conditions separate would allow the
library designer,
if he/she wants, to give the option to the user to not even compile the
conditsion.
This would allow pre/post-conditions specializations but that's another
discussion I guess.

Also, assuming a "module" world as defined by the last proposal by
microsoft (which is similar to
previous ones anyway),
having pre/post-conditions in a separate sub-module (as long as the ODR
holds)
would have similar effects if imported by default by the library author in
the exported
part of the library.


Am I missing something obvious?
Did someone already tried to explore this possibility?

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">I have been wondering this question several times through =
reading the different proposals<div>about assertions and more generally the=
 last paper N4160 analysing value constraints.</div><div>Here is an excerpt=
 from it:=C2=A0<br><br>&quot;One thing that appears non-controversial is th=
at declarations of preconditions and postconditions need to be part of func=
tion declaration, so that they are accessible by the function users who may=
 not have access to function definitions. We leave it open whether a value =
constraint declaration should affect function&#39;s signature or type or af=
fect the overload resolution mechanism; although it looks like affecting fu=
nction&#39;s type would make it impossible to retrofit value constraints in=
to the existing code.&quot;<br></div><div><br></div><div>First, I understan=
d that it might feels &quot;natural&quot; to initially consider post/pre-co=
nditions as part of the</div><div>signature. However:</div><div><br></div><=
div>=C2=A01. I didn&#39;t see any proposal even trying to explore the actua=
l properties that would have a grammar allowing (not forcing) to have pre/p=
ost-conditions expressed separately. And as explained in the following exam=
ple, I don&#39;t see major issues if...</div><div>=C2=A02. ...we assume tha=
t such value constrain feature will certainly have one or several ways=C2=
=A0</div><div>=C2=A0 =C2=A0 to chose the actual effect (ignored, statically=
 checked, runtime checked, other...)</div><div>=C2=A0 =C2=A0 =C2=A0by eithe=
r the library user or the library designer or both.</div><div>=C2=A0 =C2=A0=
 =C2=A0In this case, having a way to provide constraints as an optional sep=
arate set of=C2=A0</div><div>=C2=A0 =C2=A0 =C2=A0information about the type=
s would seem reasonable to me.</div><div><br></div><div>It seems to me that=
 pre/post-conditions could be considered the same way free functions</div><=
div>manipulating a data type would be separate but still augmenting optiona=
lly the possibilities</div><div>offered by that data type.</div><div><br></=
div><div>From N4160:</div><div><br></div><div><div>&quot;Another concern th=
at we have is that if we combine all kinds of possible function contract, l=
ike concepts, value constraints, conditions on these constraints, the decla=
rations could become unbearably long. Reconsider the example of std::find f=
rom above. In order to make it short, we made it incorrect. The postconditi=
on cannot be defined for non-ForwardIterator types. If we tried to really c=
onstrain std::find, (using some invented syntax and assuming Concepts Lite,=
 and the new Range design being proposed (see [N4128])) it would go:</div><=
div><br></div><div>template&lt;InputIterator I, Regular S, Regular V&gt;</d=
iv><div>=C2=A0 requires EqualityComparable&lt;I, S&gt; &amp;&amp; EqualityC=
omparable&lt;Value_type&lt;I&gt;, V&gt;</div><div>I find(I b, S e, const V&=
amp; v)</div><div>precondition{ is_valid_range(b, e); }</div><div>postcondi=
tion(f) {</div><div>=C2=A0 is_valid_range(b, f)</div><div>=C2=A0 =C2=A0 req=
uires ForwardIterator&lt;I&gt;;</div><div>=C2=A0 is_valid_range(f, e);</div=
><div>=C2=A0 [[contract::never_evaluate]]</div><div>=C2=A0 none_of(b, f, []=
(const Value_type&lt;I&gt;&amp; x){x =3D=3D v})</div><div>=C2=A0 =C2=A0 req=
uires ForwardIterator&lt;I&gt;;</div><div>=C2=A0 [[contract::complexity(con=
stant)]]</div><div>=C2=A0 f =3D=3D e || *f =3D=3D v=C2=A0</div><div>=C2=A0 =
=C2=A0 requires ForwardIterator&lt;I&gt;;</div><div>};</div><div>Does this =
declaration not look scary?&quot;</div></div><div><br></div><div>Taking the=
 concerning example and trying to imagine such a separation, I end-up</div>=
<div>with this:</div><div><br></div><div><div><br></div><div>// Header cont=
aining find()</div><div><br></div><div>template&lt;InputIterator I, Regular=
 S, Regular V&gt;</div><div>=C2=A0 requires EqualityComparable&lt;I, S&gt; =
&amp;&amp; EqualityComparable&lt;Value_type&lt;I&gt;, V&gt;</div><div>I fin=
d(I b, S e, const V&amp; v);</div><div><br></div><div>// Header containing =
constraints for find()</div><div>// Optionally implicitely included by the =
previous header</div><div><br></div><div>template&lt;InputIterator I, Regul=
ar S, Regular V&gt;</div><div>precondition I find(I b, S e, const V&amp; v)=
</div><div>{=C2=A0</div><div>=C2=A0 =C2=A0 is_valid_range(b, e);=C2=A0</div=
><div>}</div><div><br></div><div>template&lt;InputIterator I, Regular S, Re=
gular V&gt;</div><div>postcondition(f) I find(I b, S e, const V&amp; v)=C2=
=A0</div><div>{</div><div>=C2=A0 is_valid_range(b, f);</div><div>=C2=A0 is_=
valid_range(f, e);</div><div>=C2=A0 f =3D=3D e || *f =3D=3D v;</div><div>}<=
/div><div><br></div><div>template&lt;InputIterator I, Regular S, Regular V&=
gt;</div><div>postcondition(f) I find(I b, S e, const V&amp; v)</div><div>=
=C2=A0 =C2=A0 requires ForwardIterator&lt;I&gt;;</div><div>{</div><div>=C2=
=A0 is_valid_range(b, f)</div><div>=C2=A0 is_valid_range(f, e);</div><div>=
=C2=A0 none_of(b, f, [](const Value_type&lt;I&gt;&amp; x){x =3D=3D v});</di=
v><div>=C2=A0 f =3D=3D e || *f =3D=3D v;</div><div>}</div><div><br></div><d=
iv><br></div><div>Assume that this way of expressing the example have the e=
xact same meaning as before.</div><div>The main difference is that having t=
he conditions separate would allow the library designer,</div><div>if he/sh=
e wants, to give the option to the user to not even compile the conditsion.=
</div><div>This would allow pre/post-conditions specializations but that&#3=
9;s another discussion I guess.</div></div><div><br></div><div>Also, assumi=
ng a &quot;module&quot; world as defined by the last proposal by microsoft =
(which is similar to</div><div>previous ones anyway),</div><div>having pre/=
post-conditions in a separate sub-module (as long as the ODR holds)=C2=A0</=
div><div>would have similar effects if imported by default by the library a=
uthor in the exported</div><div>part of the library.=C2=A0</div><div><br></=
div><div><br></div><div>Am I missing something obvious?</div><div>Did someo=
ne already tried to explore this possibility?</div><div><br></div><div><br>=
</div><div><br></div><div><br></div><div><br></div><div><br></div></div>

<p></p>

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

--001a11347e0a618fe0050710c7b4--

.

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



W dniu =C5=9Broda, 5 listopada 2014 00:25:32 UTC+1 u=C5=BCytkownik Klaim - =
Jo=C3=ABl=20
Lamotte napisa=C5=82:
>
> I have been wondering this question several times through reading the=20
> different proposals
> about assertions and more generally the last paper N4160 analysing value=
=20
> constraints.
> Here is an excerpt from it:=20
>
> "One thing that appears non-controversial is that declarations of=20
> preconditions and postconditions need to be part of function declaration,=
=20
> so that they are accessible by the function users who may not have access=
=20
> to function definitions. We leave it open whether a value constraint=20
> declaration should affect function's signature or type or affect the=20
> overload resolution mechanism; although it looks like affecting function'=
s=20
> type would make it impossible to retrofit value constraints into the=20
> existing code."
>
> First, I understand that it might feels "natural" to initially consider=
=20
> post/pre-conditions as part of the
> signature. However:
>
>  1. I didn't see any proposal even trying to explore the actual propertie=
s=20
> that would have a grammar allowing (not forcing) to have=20
> pre/post-conditions expressed separately. And as explained in the followi=
ng=20
> example, I don't see major issues if...
>  2. ...we assume that such value constrain feature will certainly have on=
e=20
> or several ways=20
>     to chose the actual effect (ignored, statically checked, runtime=20
> checked, other...)
>      by either the library user or the library designer or both.
>      In this case, having a way to provide constraints as an optional=20
> separate set of=20
>      information about the types would seem reasonable to me.
>
> It seems to me that pre/post-conditions could be considered the same way=
=20
> free functions
> manipulating a data type would be separate but still augmenting optionall=
y=20
> the possibilities
> offered by that data type.
>
> From N4160:
>
> "Another concern that we have is that if we combine all kinds of possible=
=20
> function contract, like concepts, value constraints, conditions on these=
=20
> constraints, the declarations could become unbearably long. Reconsider th=
e=20
> example of std::find from above. In order to make it short, we made it=20
> incorrect. The postcondition cannot be defined for non-ForwardIterator=20
> types. If we tried to really constrain std::find, (using some invented=20
> syntax and assuming Concepts Lite, and the new Range design being propose=
d=20
> (see [N4128])) it would go:
>
> template<InputIterator I, Regular S, Regular V>
>   requires EqualityComparable<I, S> && EqualityComparable<Value_type<I>, =
V>
> I find(I b, S e, const V& v)
> precondition{ is_valid_range(b, e); }
> postcondition(f) {
>   is_valid_range(b, f)
>     requires ForwardIterator<I>;
>   is_valid_range(f, e);
>   [[contract::never_evaluate]]
>   none_of(b, f, [](const Value_type<I>& x){x =3D=3D v})
>     requires ForwardIterator<I>;
>   [[contract::complexity(constant)]]
>   f =3D=3D e || *f =3D=3D v=20
>     requires ForwardIterator<I>;
> };
> Does this declaration not look scary?"
>
> Taking the concerning example and trying to imagine such a separation, I=
=20
> end-up
> with this:
>
>
> // Header containing find()
>
> template<InputIterator I, Regular S, Regular V>
>   requires EqualityComparable<I, S> && EqualityComparable<Value_type<I>, =
V>
> I find(I b, S e, const V& v);
>
> // Header containing constraints for find()
> // Optionally implicitely included by the previous header
>
> template<InputIterator I, Regular S, Regular V>
> precondition I find(I b, S e, const V& v)
> {=20
>     is_valid_range(b, e);=20
> }
>
> template<InputIterator I, Regular S, Regular V>
> postcondition(f) I find(I b, S e, const V& v)=20
> {
>   is_valid_range(b, f);
>   is_valid_range(f, e);
>   f =3D=3D e || *f =3D=3D v;
> }
>
> template<InputIterator I, Regular S, Regular V>
> postcondition(f) I find(I b, S e, const V& v)
>     requires ForwardIterator<I>;
> {
>   is_valid_range(b, f)
>   is_valid_range(f, e);
>   none_of(b, f, [](const Value_type<I>& x){x =3D=3D v});
>   f =3D=3D e || *f =3D=3D v;
> }
>
>
> Assume that this way of expressing the example have the exact same meanin=
g=20
> as before.
> The main difference is that having the conditions separate would allow th=
e=20
> library designer,
> if he/she wants, to give the option to the user to not even compile the=
=20
> conditsion.
> This would allow pre/post-conditions specializations but that's another=
=20
> discussion I guess.
>
> Also, assuming a "module" world as defined by the last proposal by=20
> microsoft (which is similar to
> previous ones anyway),
> having pre/post-conditions in a separate sub-module (as long as the ODR=
=20
> holds)=20
> would have similar effects if imported by default by the library author i=
n=20
> the exported
> part of the library.=20
>
>
> Am I missing something obvious?
> Did someone already tried to explore this possibility?
>

This is an interesting perspective. I know other proposals put focus on=20
some run-time behavior, so I do not know how your suggestion fits with=20
them. If the goal of value constraints were only to assist with static=20
analysis, it is by all means possible to deliver them separately. What=20
makes me uncomfortable about this separation is not technical reasons, but=
=20
moral/philosophical ones. These value constraints are part of function=20
"contract" - like whether it is constexpr or noexcept, if it mutates the=20
arguments or not, whether the arguments are allowed to alias, etc. and it=
=20
just "belongs" there. I consider the declaration a contract between the=20
implementer and the users.=20

--=20

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

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

<div dir=3D"ltr"><br><br>W dniu =C5=9Broda, 5 listopada 2014 00:25:32 UTC+1=
 u=C5=BCytkownik Klaim - Jo=C3=ABl Lamotte napisa=C5=82:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr">I have been wondering this que=
stion several times through reading the different proposals<div>about asser=
tions and more generally the last paper N4160 analysing value constraints.<=
/div><div>Here is an excerpt from it:&nbsp;<br><br>"One thing that appears =
non-controversial is that declarations of preconditions and postconditions =
need to be part of function declaration, so that they are accessible by the=
 function users who may not have access to function definitions. We leave i=
t open whether a value constraint declaration should affect function's sign=
ature or type or affect the overload resolution mechanism; although it look=
s like affecting function's type would make it impossible to retrofit value=
 constraints into the existing code."<br></div><div><br></div><div>First, I=
 understand that it might feels "natural" to initially consider post/pre-co=
nditions as part of the</div><div>signature. However:</div><div><br></div><=
div>&nbsp;1. I didn't see any proposal even trying to explore the actual pr=
operties that would have a grammar allowing (not forcing) to have pre/post-=
conditions expressed separately. And as explained in the following example,=
 I don't see major issues if...</div><div>&nbsp;2. ...we assume that such v=
alue constrain feature will certainly have one or several ways&nbsp;</div><=
div>&nbsp; &nbsp; to chose the actual effect (ignored, statically checked, =
runtime checked, other...)</div><div>&nbsp; &nbsp; &nbsp;by either the libr=
ary user or the library designer or both.</div><div>&nbsp; &nbsp; &nbsp;In =
this case, having a way to provide constraints as an optional separate set =
of&nbsp;</div><div>&nbsp; &nbsp; &nbsp;information about the types would se=
em reasonable to me.</div><div><br></div><div>It seems to me that pre/post-=
conditions could be considered the same way free functions</div><div>manipu=
lating a data type would be separate but still augmenting optionally the po=
ssibilities</div><div>offered by that data type.</div><div><br></div><div>F=
rom N4160:</div><div><br></div><div><div>"Another concern that we have is t=
hat if we combine all kinds of possible function contract, like concepts, v=
alue constraints, conditions on these constraints, the declarations could b=
ecome unbearably long. Reconsider the example of std::find from above. In o=
rder to make it short, we made it incorrect. The postcondition cannot be de=
fined for non-ForwardIterator types. If we tried to really constrain std::f=
ind, (using some invented syntax and assuming Concepts Lite, and the new Ra=
nge design being proposed (see [N4128])) it would go:</div><div><br></div><=
div>template&lt;InputIterator I, Regular S, Regular V&gt;</div><div>&nbsp; =
requires EqualityComparable&lt;I, S&gt; &amp;&amp; EqualityComparable&lt;Va=
lue_type&lt;<wbr>I&gt;, V&gt;</div><div>I find(I b, S e, const V&amp; v)</d=
iv><div>precondition{ is_valid_range(b, e); }</div><div>postcondition(f) {<=
/div><div>&nbsp; is_valid_range(b, f)</div><div>&nbsp; &nbsp; requires Forw=
ardIterator&lt;I&gt;;</div><div>&nbsp; is_valid_range(f, e);</div><div>&nbs=
p; [[contract::never_evaluate]]</div><div>&nbsp; none_of(b, f, [](const Val=
ue_type&lt;I&gt;&amp; x){x =3D=3D v})</div><div>&nbsp; &nbsp; requires Forw=
ardIterator&lt;I&gt;;</div><div>&nbsp; [[contract::complexity(<wbr>constant=
)]]</div><div>&nbsp; f =3D=3D e || *f =3D=3D v&nbsp;</div><div>&nbsp; &nbsp=
; requires ForwardIterator&lt;I&gt;;</div><div>};</div><div>Does this decla=
ration not look scary?"</div></div><div><br></div><div>Taking the concernin=
g example and trying to imagine such a separation, I end-up</div><div>with =
this:</div><div><br></div><div><div><br></div><div>// Header containing fin=
d()</div><div><br></div><div>template&lt;InputIterator I, Regular S, Regula=
r V&gt;</div><div>&nbsp; requires EqualityComparable&lt;I, S&gt; &amp;&amp;=
 EqualityComparable&lt;Value_type&lt;<wbr>I&gt;, V&gt;</div><div>I find(I b=
, S e, const V&amp; v);</div><div><br></div><div>// Header containing const=
raints for find()</div><div>// Optionally implicitely included by the previ=
ous header</div><div><br></div><div>template&lt;InputIterator I, Regular S,=
 Regular V&gt;</div><div>precondition I find(I b, S e, const V&amp; v)</div=
><div>{&nbsp;</div><div>&nbsp; &nbsp; is_valid_range(b, e);&nbsp;</div><div=
>}</div><div><br></div><div>template&lt;InputIterator I, Regular S, Regular=
 V&gt;</div><div>postcondition(f) I find(I b, S e, const V&amp; v)&nbsp;</d=
iv><div>{</div><div>&nbsp; is_valid_range(b, f);</div><div>&nbsp; is_valid_=
range(f, e);</div><div>&nbsp; f =3D=3D e || *f =3D=3D v;</div><div>}</div><=
div><br></div><div>template&lt;InputIterator I, Regular S, Regular V&gt;</d=
iv><div>postcondition(f) I find(I b, S e, const V&amp; v)</div><div>&nbsp; =
&nbsp; requires ForwardIterator&lt;I&gt;;</div><div>{</div><div>&nbsp; is_v=
alid_range(b, f)</div><div>&nbsp; is_valid_range(f, e);</div><div>&nbsp; no=
ne_of(b, f, [](const Value_type&lt;I&gt;&amp; x){x =3D=3D v});</div><div>&n=
bsp; f =3D=3D e || *f =3D=3D v;</div><div>}</div><div><br></div><div><br></=
div><div>Assume that this way of expressing the example have the exact same=
 meaning as before.</div><div>The main difference is that having the condit=
ions separate would allow the library designer,</div><div>if he/she wants, =
to give the option to the user to not even compile the conditsion.</div><di=
v>This would allow pre/post-conditions specializations but that's another d=
iscussion I guess.</div></div><div><br></div><div>Also, assuming a "module"=
 world as defined by the last proposal by microsoft (which is similar to</d=
iv><div>previous ones anyway),</div><div>having pre/post-conditions in a se=
parate sub-module (as long as the ODR holds)&nbsp;</div><div>would have sim=
ilar effects if imported by default by the library author in the exported</=
div><div>part of the library.&nbsp;</div><div><br></div><div><br></div><div=
>Am I missing something obvious?</div><div>Did someone already tried to exp=
lore this possibility?</div></div></blockquote><div><br>This is an interest=
ing perspective. I know other proposals put focus on some run-time behavior=
, so I do not know how your suggestion fits with them. If the goal of value=
 constraints were only to assist with static analysis, it is by all means p=
ossible to deliver them separately. What makes me uncomfortable about this =
separation is not technical reasons, but moral/philosophical ones. These va=
lue constraints are part of function "contract" - like whether it is conste=
xpr or noexcept, if it mutates the arguments or not, whether the arguments =
are allowed to alias, etc. and it just "belongs" there. I consider the decl=
aration a contract between the implementer and the users. <br></div></div>

<p></p>

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

------=_Part_354_77343835.1415369808375--

.

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

I globally agree with your viewpoint. However, depending on the choices
made by an implementation of such
contracts, it seems that this is a pragmatic possibility that should not be
dismissed.
For example, if one implementation/proposal decides that overloading is not
impacted by such contracts and
that checking contracts (whatever the way) is optional, then allowing (but
still not forcing) such separation can have
some benefits.

By the way (not exactly the same subject/idea, just an idea),
now let's assume that we really really wants to have contracts being part
of the interface, as you prefer.
Then there might still be a way to separate it from the function signature,
by giving it a name
which is used by the signature to let the compiler knows that there is a
contract required.
The compiler would then report an error if the contract have not been
defined before the end of the compilation unit.
It seems close to what is already planned for Concepts (but concepts have
to be defined before use).
Something like:


template<InputIterator I, Regular S, Regular V>
  requires EqualityComparable<I, S> && EqualityComparable<Value_type<I>, V>
I find(I b, S e, const V& v) contract;  // will not compile if
find_contract is not defined

template<InputIterator I, Regular S, Regular V>
contract I find(I b, S e, const V& v) // might be overloaded like in my
previous example?
{
    precondition{ ... }
    postcondition(f) {
      ...
      }
};


Would it help with having contracts part of signatures but not bloat the
core of the signature?


On Fri, Nov 7, 2014 at 3:16 PM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.co=
m>
wrote:

>
>
> W dniu =C5=9Broda, 5 listopada 2014 00:25:32 UTC+1 u=C5=BCytkownik Klaim =
- Jo=C3=ABl
> Lamotte napisa=C5=82:
>
>> I have been wondering this question several times through reading the
>> different proposals
>> about assertions and more generally the last paper N4160 analysing value
>> constraints.
>> Here is an excerpt from it:
>>
>> "One thing that appears non-controversial is that declarations of
>> preconditions and postconditions need to be part of function declaration=
,
>> so that they are accessible by the function users who may not have acces=
s
>> to function definitions. We leave it open whether a value constraint
>> declaration should affect function's signature or type or affect the
>> overload resolution mechanism; although it looks like affecting function=
's
>> type would make it impossible to retrofit value constraints into the
>> existing code."
>>
>> First, I understand that it might feels "natural" to initially consider
>> post/pre-conditions as part of the
>> signature. However:
>>
>>  1. I didn't see any proposal even trying to explore the actual
>> properties that would have a grammar allowing (not forcing) to have
>> pre/post-conditions expressed separately. And as explained in the follow=
ing
>> example, I don't see major issues if...
>>  2. ...we assume that such value constrain feature will certainly have
>> one or several ways
>>     to chose the actual effect (ignored, statically checked, runtime
>> checked, other...)
>>      by either the library user or the library designer or both.
>>      In this case, having a way to provide constraints as an optional
>> separate set of
>>      information about the types would seem reasonable to me.
>>
>> It seems to me that pre/post-conditions could be considered the same way
>> free functions
>> manipulating a data type would be separate but still augmenting
>> optionally the possibilities
>> offered by that data type.
>>
>> From N4160:
>>
>> "Another concern that we have is that if we combine all kinds of possibl=
e
>> function contract, like concepts, value constraints, conditions on these
>> constraints, the declarations could become unbearably long. Reconsider t=
he
>> example of std::find from above. In order to make it short, we made it
>> incorrect. The postcondition cannot be defined for non-ForwardIterator
>> types. If we tried to really constrain std::find, (using some invented
>> syntax and assuming Concepts Lite, and the new Range design being propos=
ed
>> (see [N4128])) it would go:
>>
>> template<InputIterator I, Regular S, Regular V>
>>   requires EqualityComparable<I, S> && EqualityComparable<Value_type<I>,
>> V>
>> I find(I b, S e, const V& v)
>> precondition{ is_valid_range(b, e); }
>> postcondition(f) {
>>   is_valid_range(b, f)
>>     requires ForwardIterator<I>;
>>   is_valid_range(f, e);
>>   [[contract::never_evaluate]]
>>   none_of(b, f, [](const Value_type<I>& x){x =3D=3D v})
>>     requires ForwardIterator<I>;
>>   [[contract::complexity(constant)]]
>>   f =3D=3D e || *f =3D=3D v
>>     requires ForwardIterator<I>;
>> };
>> Does this declaration not look scary?"
>>
>> Taking the concerning example and trying to imagine such a separation, I
>> end-up
>> with this:
>>
>>
>> // Header containing find()
>>
>> template<InputIterator I, Regular S, Regular V>
>>   requires EqualityComparable<I, S> && EqualityComparable<Value_type<I>,
>> V>
>> I find(I b, S e, const V& v);
>>
>> // Header containing constraints for find()
>> // Optionally implicitely included by the previous header
>>
>> template<InputIterator I, Regular S, Regular V>
>> precondition I find(I b, S e, const V& v)
>> {
>>     is_valid_range(b, e);
>> }
>>
>> template<InputIterator I, Regular S, Regular V>
>> postcondition(f) I find(I b, S e, const V& v)
>> {
>>   is_valid_range(b, f);
>>   is_valid_range(f, e);
>>   f =3D=3D e || *f =3D=3D v;
>> }
>>
>> template<InputIterator I, Regular S, Regular V>
>> postcondition(f) I find(I b, S e, const V& v)
>>     requires ForwardIterator<I>;
>> {
>>   is_valid_range(b, f)
>>   is_valid_range(f, e);
>>   none_of(b, f, [](const Value_type<I>& x){x =3D=3D v});
>>   f =3D=3D e || *f =3D=3D v;
>> }
>>
>>
>> Assume that this way of expressing the example have the exact same
>> meaning as before.
>> The main difference is that having the conditions separate would allow
>> the library designer,
>> if he/she wants, to give the option to the user to not even compile the
>> conditsion.
>> This would allow pre/post-conditions specializations but that's another
>> discussion I guess.
>>
>> Also, assuming a "module" world as defined by the last proposal by
>> microsoft (which is similar to
>> previous ones anyway),
>> having pre/post-conditions in a separate sub-module (as long as the ODR
>> holds)
>> would have similar effects if imported by default by the library author
>> in the exported
>> part of the library.
>>
>>
>> Am I missing something obvious?
>> Did someone already tried to explore this possibility?
>>
>
> This is an interesting perspective. I know other proposals put focus on
> some run-time behavior, so I do not know how your suggestion fits with
> them. If the goal of value constraints were only to assist with static
> analysis, it is by all means possible to deliver them separately. What
> makes me uncomfortable about this separation is not technical reasons, bu=
t
> moral/philosophical ones. These value constraints are part of function
> "contract" - like whether it is constexpr or noexcept, if it mutates the
> arguments or not, whether the arguments are allowed to alias, etc. and it
> just "belongs" there. I consider the declaration a contract between the
> implementer and the users.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

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

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

<div dir=3D"ltr">I globally agree with your viewpoint. However, depending o=
n the choices made by an implementation of such=C2=A0<br><div>contracts, it=
 seems that this is a pragmatic possibility that should not be dismissed.=
=C2=A0</div><div>For example, if one implementation/proposal decides that o=
verloading is not impacted by such contracts and=C2=A0</div><div>that check=
ing contracts (whatever the way) is optional, then allowing (but still not =
forcing) such separation can have=C2=A0</div><div>some benefits.</div><div>=
<br></div><div>By the way (not exactly the same subject/idea, just an idea)=
, <br>now let&#39;s assume that we really really wants to have contracts be=
ing part of the interface, as you prefer.</div><div>Then there might still =
be a way to separate it from the function signature, by giving it a name</d=
iv><div>which is used by the signature to let the compiler knows that there=
 is a contract required. <br>The compiler would then report an error if the=
 contract have not been</div><div>defined before the end of the compilation=
 unit.<br>It seems close to what is already planned for Concepts (but conce=
pts have to be defined before use).</div><div>Something like:</div><div><br=
></div><div><br></div><div><div style=3D"font-family:arial,sans-serif;font-=
size:13px">template&lt;InputIterator I, Regular S, Regular V&gt;</div><div =
style=3D"font-family:arial,sans-serif;font-size:13px">=C2=A0 requires Equal=
ityComparable&lt;I, S&gt; &amp;&amp; EqualityComparable&lt;Value_type&lt;I&=
gt;, V&gt;</div><div style=3D"font-family:arial,sans-serif;font-size:13px">=
I find(I b, S e, const V&amp; v) contract; =C2=A0// will not compile if fin=
d_contract is not defined</div><div style=3D"font-family:arial,sans-serif;f=
ont-size:13px"><br></div><div style=3D"font-family:arial,sans-serif;font-si=
ze:13px">template&lt;InputIterator I, Regular S, Regular V&gt;<br></div><di=
v style=3D"font-family:arial,sans-serif;font-size:13px">contract I find(I b=
, S e, const V&amp; v) // might be overloaded like in my previous example?<=
/div><div style=3D"font-family:arial,sans-serif;font-size:13px">{</div><div=
 style=3D"font-family:arial,sans-serif;font-size:13px">=C2=A0 =C2=A0 precon=
dition{ ... }</div><div style=3D"font-family:arial,sans-serif;font-size:13p=
x">=C2=A0 =C2=A0 postcondition(f) {</div><div style=3D"font-family:arial,sa=
ns-serif;font-size:13px">=C2=A0 =C2=A0 =C2=A0 ...</div><div style=3D"font-f=
amily:arial,sans-serif;font-size:13px">=C2=A0 =C2=A0 =C2=A0 }</div><div sty=
le=3D"font-family:arial,sans-serif;font-size:13px">};<br></div></div><div><=
br></div><div><br></div><div>Would it help with having contracts part of si=
gnatures but not bloat the core of the signature?</div><div><br></div></div=
><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Nov 7, 2=
014 at 3:16 PM, Andrzej Krzemie=C5=84ski <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:akrzemi1@gmail.com" target=3D"_blank">akrzemi1@gmail.com</a>&gt;</spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br>W dniu=
 =C5=9Broda, 5 listopada 2014 00:25:32 UTC+1 u=C5=BCytkownik Klaim - Jo=C3=
=ABl Lamotte napisa=C5=82:<div><div class=3D"h5"><blockquote class=3D"gmail=
_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">I have been wondering this question several =
times through reading the different proposals<div>about assertions and more=
 generally the last paper N4160 analysing value constraints.</div><div>Here=
 is an excerpt from it:=C2=A0<br><br>&quot;One thing that appears non-contr=
oversial is that declarations of preconditions and postconditions need to b=
e part of function declaration, so that they are accessible by the function=
 users who may not have access to function definitions. We leave it open wh=
ether a value constraint declaration should affect function&#39;s signature=
 or type or affect the overload resolution mechanism; although it looks lik=
e affecting function&#39;s type would make it impossible to retrofit value =
constraints into the existing code.&quot;<br></div><div><br></div><div>Firs=
t, I understand that it might feels &quot;natural&quot; to initially consid=
er post/pre-conditions as part of the</div><div>signature. However:</div><d=
iv><br></div><div>=C2=A01. I didn&#39;t see any proposal even trying to exp=
lore the actual properties that would have a grammar allowing (not forcing)=
 to have pre/post-conditions expressed separately. And as explained in the =
following example, I don&#39;t see major issues if...</div><div>=C2=A02. ..=
..we assume that such value constrain feature will certainly have one or sev=
eral ways=C2=A0</div><div>=C2=A0 =C2=A0 to chose the actual effect (ignored=
, statically checked, runtime checked, other...)</div><div>=C2=A0 =C2=A0 =
=C2=A0by either the library user or the library designer or both.</div><div=
>=C2=A0 =C2=A0 =C2=A0In this case, having a way to provide constraints as a=
n optional separate set of=C2=A0</div><div>=C2=A0 =C2=A0 =C2=A0information =
about the types would seem reasonable to me.</div><div><br></div><div>It se=
ems to me that pre/post-conditions could be considered the same way free fu=
nctions</div><div>manipulating a data type would be separate but still augm=
enting optionally the possibilities</div><div>offered by that data type.</d=
iv><div><br></div><div>From N4160:</div><div><br></div><div><div>&quot;Anot=
her concern that we have is that if we combine all kinds of possible functi=
on contract, like concepts, value constraints, conditions on these constrai=
nts, the declarations could become unbearably long. Reconsider the example =
of std::find from above. In order to make it short, we made it incorrect. T=
he postcondition cannot be defined for non-ForwardIterator types. If we tri=
ed to really constrain std::find, (using some invented syntax and assuming =
Concepts Lite, and the new Range design being proposed (see [N4128])) it wo=
uld go:</div><div><br></div><div>template&lt;InputIterator I, Regular S, Re=
gular V&gt;</div><div>=C2=A0 requires EqualityComparable&lt;I, S&gt; &amp;&=
amp; EqualityComparable&lt;Value_type&lt;<u></u>I&gt;, V&gt;</div><div>I fi=
nd(I b, S e, const V&amp; v)</div><div>precondition{ is_valid_range(b, e); =
}</div><div>postcondition(f) {</div><div>=C2=A0 is_valid_range(b, f)</div><=
div>=C2=A0 =C2=A0 requires ForwardIterator&lt;I&gt;;</div><div>=C2=A0 is_va=
lid_range(f, e);</div><div>=C2=A0 [[contract::never_evaluate]]</div><div>=
=C2=A0 none_of(b, f, [](const Value_type&lt;I&gt;&amp; x){x =3D=3D v})</div=
><div>=C2=A0 =C2=A0 requires ForwardIterator&lt;I&gt;;</div><div>=C2=A0 [[c=
ontract::complexity(<u></u>constant)]]</div><div>=C2=A0 f =3D=3D e || *f =
=3D=3D v=C2=A0</div><div>=C2=A0 =C2=A0 requires ForwardIterator&lt;I&gt;;</=
div><div>};</div><div>Does this declaration not look scary?&quot;</div></di=
v><div><br></div><div>Taking the concerning example and trying to imagine s=
uch a separation, I end-up</div><div>with this:</div><div><br></div><div><d=
iv><br></div><div>// Header containing find()</div><div><br></div><div>temp=
late&lt;InputIterator I, Regular S, Regular V&gt;</div><div>=C2=A0 requires=
 EqualityComparable&lt;I, S&gt; &amp;&amp; EqualityComparable&lt;Value_type=
&lt;<u></u>I&gt;, V&gt;</div><div>I find(I b, S e, const V&amp; v);</div><d=
iv><br></div><div>// Header containing constraints for find()</div><div>// =
Optionally implicitely included by the previous header</div><div><br></div>=
<div>template&lt;InputIterator I, Regular S, Regular V&gt;</div><div>precon=
dition I find(I b, S e, const V&amp; v)</div><div>{=C2=A0</div><div>=C2=A0 =
=C2=A0 is_valid_range(b, e);=C2=A0</div><div>}</div><div><br></div><div>tem=
plate&lt;InputIterator I, Regular S, Regular V&gt;</div><div>postcondition(=
f) I find(I b, S e, const V&amp; v)=C2=A0</div><div>{</div><div>=C2=A0 is_v=
alid_range(b, f);</div><div>=C2=A0 is_valid_range(f, e);</div><div>=C2=A0 f=
 =3D=3D e || *f =3D=3D v;</div><div>}</div><div><br></div><div>template&lt;=
InputIterator I, Regular S, Regular V&gt;</div><div>postcondition(f) I find=
(I b, S e, const V&amp; v)</div><div>=C2=A0 =C2=A0 requires ForwardIterator=
&lt;I&gt;;</div><div>{</div><div>=C2=A0 is_valid_range(b, f)</div><div>=C2=
=A0 is_valid_range(f, e);</div><div>=C2=A0 none_of(b, f, [](const Value_typ=
e&lt;I&gt;&amp; x){x =3D=3D v});</div><div>=C2=A0 f =3D=3D e || *f =3D=3D v=
;</div><div>}</div><div><br></div><div><br></div><div>Assume that this way =
of expressing the example have the exact same meaning as before.</div><div>=
The main difference is that having the conditions separate would allow the =
library designer,</div><div>if he/she wants, to give the option to the user=
 to not even compile the conditsion.</div><div>This would allow pre/post-co=
nditions specializations but that&#39;s another discussion I guess.</div></=
div><div><br></div><div>Also, assuming a &quot;module&quot; world as define=
d by the last proposal by microsoft (which is similar to</div><div>previous=
 ones anyway),</div><div>having pre/post-conditions in a separate sub-modul=
e (as long as the ODR holds)=C2=A0</div><div>would have similar effects if =
imported by default by the library author in the exported</div><div>part of=
 the library.=C2=A0</div><div><br></div><div><br></div><div>Am I missing so=
mething obvious?</div><div>Did someone already tried to explore this possib=
ility?</div></div></blockquote></div></div><div><br>This is an interesting =
perspective. I know other proposals put focus on some run-time behavior, so=
 I do not know how your suggestion fits with them. If the goal of value con=
straints were only to assist with static analysis, it is by all means possi=
ble to deliver them separately. What makes me uncomfortable about this sepa=
ration is not technical reasons, but moral/philosophical ones. These value =
constraints are part of function &quot;contract&quot; - like whether it is =
constexpr or noexcept, if it mutates the arguments or not, whether the argu=
ments are allowed to alias, etc. and it just &quot;belongs&quot; there. I c=
onsider the declaration a contract between the implementer and the users. <=
br></div></div><span class=3D"HOEnZb"><font color=3D"#888888">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>

<p></p>

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

--001a11c365feae535a0507465b75--

.

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



W dniu pi=C4=85tek, 7 listopada 2014 16:20:54 UTC+1 u=C5=BCytkownik Klaim -=
 Jo=C3=ABl=20
Lamotte napisa=C5=82:
>
> I globally agree with your viewpoint. However, depending on the choices=
=20
> made by an implementation of such=20
> contracts, it seems that this is a pragmatic possibility that should not=
=20
> be dismissed.=20
> For example, if one implementation/proposal decides that overloading is=
=20
> not impacted by such contracts and=20
> that checking contracts (whatever the way) is optional, then allowing (bu=
t=20
> still not forcing) such separation can have=20
> some benefits.
>
> By the way (not exactly the same subject/idea, just an idea),=20
> now let's assume that we really really wants to have contracts being part=
=20
> of the interface, as you prefer.
> Then there might still be a way to separate it from the function=20
> signature, by giving it a name
> which is used by the signature to let the compiler knows that there is a=
=20
> contract required.=20
> The compiler would then report an error if the contract have not been
> defined before the end of the compilation unit.
> It seems close to what is already planned for Concepts (but concepts have=
=20
> to be defined before use).
> Something like:
>
>
> template<InputIterator I, Regular S, Regular V>
>   requires EqualityComparable<I, S> && EqualityComparable<Value_type<I>, =
V>
> I find(I b, S e, const V& v) contract;  // will not compile if=20
> find_contract is not defined
>
> template<InputIterator I, Regular S, Regular V>
> contract I find(I b, S e, const V& v) // might be overloaded like in my=
=20
> previous example?
> {
>     precondition{ ... }
>     postcondition(f) {
>       ...
>       }
> };
>
>
> Would it help with having contracts part of signatures but not bloat the=
=20
> core of the signature?
>
=20
I like the idea. It looks feasible, at least at the first sight.=20

We shall see how the proposals are received by the Committee, before trying=
=20
to improve this one. Personally, I think none of them will be accepted.=20
Adding any run-time checks is suspicious, and may be leading the way in the=
=20
wrong direction. Supporting static analysis may be attractive, but before=
=20
any such static analyzer is built, we cannot determine what support is=20
needed and if it is helpful at all.

--=20

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

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

<div dir=3D"ltr"><br><br>W dniu pi=C4=85tek, 7 listopada 2014 16:20:54 UTC+=
1 u=C5=BCytkownik Klaim - Jo=C3=ABl Lamotte napisa=C5=82:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr">I globally agree with your vie=
wpoint. However, depending on the choices made by an implementation of such=
&nbsp;<br><div>contracts, it seems that this is a pragmatic possibility tha=
t should not be dismissed.&nbsp;</div><div>For example, if one implementati=
on/proposal decides that overloading is not impacted by such contracts and&=
nbsp;</div><div>that checking contracts (whatever the way) is optional, the=
n allowing (but still not forcing) such separation can have&nbsp;</div><div=
>some benefits.</div><div><br></div><div>By the way (not exactly the same s=
ubject/idea, just an idea), <br>now let's assume that we really really want=
s to have contracts being part of the interface, as you prefer.</div><div>T=
hen there might still be a way to separate it from the function signature, =
by giving it a name</div><div>which is used by the signature to let the com=
piler knows that there is a contract required. <br>The compiler would then =
report an error if the contract have not been</div><div>defined before the =
end of the compilation unit.<br>It seems close to what is already planned f=
or Concepts (but concepts have to be defined before use).</div><div>Somethi=
ng like:</div><div><br></div><div><br></div><div><div style=3D"font-family:=
arial,sans-serif;font-size:13px">template&lt;InputIterator I, Regular S, Re=
gular V&gt;</div><div style=3D"font-family:arial,sans-serif;font-size:13px"=
>&nbsp; requires EqualityComparable&lt;I, S&gt; &amp;&amp; EqualityComparab=
le&lt;Value_type&lt;<wbr>I&gt;, V&gt;</div><div style=3D"font-family:arial,=
sans-serif;font-size:13px">I find(I b, S e, const V&amp; v) contract; &nbsp=
;// will not compile if find_contract is not defined</div><div style=3D"fon=
t-family:arial,sans-serif;font-size:13px"><br></div><div style=3D"font-fami=
ly:arial,sans-serif;font-size:13px">template&lt;InputIterator I, Regular S,=
 Regular V&gt;<br></div><div style=3D"font-family:arial,sans-serif;font-siz=
e:13px">contract I find(I b, S e, const V&amp; v) // might be overloaded li=
ke in my previous example?</div><div style=3D"font-family:arial,sans-serif;=
font-size:13px">{</div><div style=3D"font-family:arial,sans-serif;font-size=
:13px">&nbsp; &nbsp; precondition{ ... }</div><div style=3D"font-family:ari=
al,sans-serif;font-size:13px">&nbsp; &nbsp; postcondition(f) {</div><div st=
yle=3D"font-family:arial,sans-serif;font-size:13px">&nbsp; &nbsp; &nbsp; ..=
..</div><div style=3D"font-family:arial,sans-serif;font-size:13px">&nbsp; &n=
bsp; &nbsp; }</div><div style=3D"font-family:arial,sans-serif;font-size:13p=
x">};<br></div></div><div><br></div><div><br></div><div>Would it help with =
having contracts part of signatures but not bloat the core of the signature=
?</div></div></blockquote><div>&nbsp;<br>I like the idea. It looks feasible=
, at least at the first sight. <br><br>We shall see how the proposals are r=
eceived by the Committee, before trying to improve this one. Personally, I =
think none of them will be accepted. Adding any run-time checks is suspicio=
us, and may be leading the way in the wrong direction. Supporting static an=
alysis may be attractive, but before any such static analyzer is built, we =
cannot determine what support is needed and if it is helpful at all.<br></d=
iv></div>

<p></p>

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

------=_Part_102_2111569808.1415379317582--

.

<html><head></head><body style=3D"background-color: rgb(255, 255, 255); lin=
e-height: initial;">                                                       =
                               <div style=3D"width: 100%; font-size: initia=
l; font-family: Calibri, 'Slate Pro', sans-serif; color: rgb(31, 73, 125); =
text-align: initial; background-color: rgb(255, 255, 255);">The committee l=
ooked at some contracts papers this week and, in general, voted in favour o=
r contracts and in favour =E2=80=8Eof having them in the signature.&nbsp;</=
div><div style=3D"width: 100%; font-size: initial; font-family: Calibri, 'S=
late Pro', sans-serif; color: rgb(31, 73, 125); text-align: initial; backgr=
ound-color: rgb(255, 255, 255);"><br></div><div style=3D"width: 100%; font-=
size: initial; font-family: Calibri, 'Slate Pro', sans-serif; color: rgb(31=
, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">I t=
hink taking a common contract and giving it I name is also a good idea.</di=
v><div style=3D"width: 100%; font-size: initial; font-family: Calibri, 'Sla=
te Pro', sans-serif; color: rgb(31, 73, 125); text-align: initial; backgrou=
nd-color: rgb(255, 255, 255);"><br></div>                                  =
                                                                           =
                        <div style=3D"width: 100%; font-size: initial; font=
-family: Calibri, 'Slate Pro', sans-serif; color: rgb(31, 73, 125); text-al=
ign: initial; background-color: rgb(255, 255, 255);"><br style=3D"display:i=
nitial"></div>                                                             =
                                                                        <di=
v style=3D"font-size: initial; font-family: Calibri, 'Slate Pro', sans-seri=
f; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255,=
 255, 255);">Sent from my BlackBerry 10 smartphone.</div>                  =
                                                                           =
                                                                           =
          <table width=3D"100%" style=3D"background-color:white;border-spac=
ing:0px;"> <tbody><tr><td colspan=3D"2" style=3D"font-size: initial; text-a=
lign: initial; background-color: rgb(255, 255, 255);">                     =
      <div style=3D"border-style: solid none none; border-top-color: rgb(18=
1, 196, 223); border-top-width: 1pt; padding: 3pt 0in 0in; font-family: Tah=
oma, 'BB Alpha Sans', 'Slate Pro'; font-size: 10pt;">  <div><b>From: </b>An=
drzej Krzemie=C5=84ski</div><div><b>Sent: </b>Friday, November 7, 2014 11:5=
5 AM</div><div><b>To: </b>std-proposals@isocpp.org</div><div><b>Reply To: <=
/b>std-proposals@isocpp.org</div><div><b>Subject: </b>Re: [std-proposals] R=
e: [N4160-Value Constraints] Why would pre/post-conditions have to be part =
of the signature?</div></div></td></tr></tbody></table><div style=3D"border=
-style: solid none none; border-top-color: rgb(186, 188, 209); border-top-w=
idth: 1pt; font-size: initial; text-align: initial; background-color: rgb(2=
55, 255, 255);"></div><br><div id=3D"_originalContent" style=3D""><div dir=
=3D"ltr"><br><br>W dniu pi=C4=85tek, 7 listopada 2014 16:20:54 UTC+1 u=C5=
=BCytkownik Klaim - Jo=C3=ABl Lamotte napisa=C5=82:<blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;"><div dir=3D"ltr">I globally agree with your viewpoint.=
 However, depending on the choices made by an implementation of such&nbsp;<=
br><div>contracts, it seems that this is a pragmatic possibility that shoul=
d not be dismissed.&nbsp;</div><div>For example, if one implementation/prop=
osal decides that overloading is not impacted by such contracts and&nbsp;</=
div><div>that checking contracts (whatever the way) is optional, then allow=
ing (but still not forcing) such separation can have&nbsp;</div><div>some b=
enefits.</div><div><br></div><div>By the way (not exactly the same subject/=
idea, just an idea), <br>now let's assume that we really really wants to ha=
ve contracts being part of the interface, as you prefer.</div><div>Then the=
re might still be a way to separate it from the function signature, by givi=
ng it a name</div><div>which is used by the signature to let the compiler k=
nows that there is a contract required. <br>The compiler would then report =
an error if the contract have not been</div><div>defined before the end of =
the compilation unit.<br>It seems close to what is already planned for Conc=
epts (but concepts have to be defined before use).</div><div>Something like=
:</div><div><br></div><div><br></div><div><div style=3D"font-family:arial,s=
ans-serif;font-size:13px">template&lt;InputIterator I, Regular S, Regular V=
&gt;</div><div style=3D"font-family:arial,sans-serif;font-size:13px">&nbsp;=
 requires EqualityComparable&lt;I, S&gt; &amp;&amp; EqualityComparable&lt;V=
alue_type&lt;<wbr>I&gt;, V&gt;</div><div style=3D"font-family:arial,sans-se=
rif;font-size:13px">I find(I b, S e, const V&amp; v) contract; &nbsp;// wil=
l not compile if find_contract is not defined</div><div style=3D"font-famil=
y:arial,sans-serif;font-size:13px"><br></div><div style=3D"font-family:aria=
l,sans-serif;font-size:13px">template&lt;InputIterator I, Regular S, Regula=
r V&gt;<br></div><div style=3D"font-family:arial,sans-serif;font-size:13px"=
>contract I find(I b, S e, const V&amp; v) // might be overloaded like in m=
y previous example?</div><div style=3D"font-family:arial,sans-serif;font-si=
ze:13px">{</div><div style=3D"font-family:arial,sans-serif;font-size:13px">=
&nbsp; &nbsp; precondition{ ... }</div><div style=3D"font-family:arial,sans=
-serif;font-size:13px">&nbsp; &nbsp; postcondition(f) {</div><div style=3D"=
font-family:arial,sans-serif;font-size:13px">&nbsp; &nbsp; &nbsp; ...</div>=
<div style=3D"font-family:arial,sans-serif;font-size:13px">&nbsp; &nbsp; &n=
bsp; }</div><div style=3D"font-family:arial,sans-serif;font-size:13px">};<b=
r></div></div><div><br></div><div><br></div><div>Would it help with having =
contracts part of signatures but not bloat the core of the signature?</div>=
</div></blockquote><div>&nbsp;<br>I like the idea. It looks feasible, at le=
ast at the first sight. <br><br>We shall see how the proposals are received=
 by the Committee, before trying to improve this one. Personally, I think n=
one of them will be accepted. Adding any run-time checks is suspicious, and=
 may be leading the way in the wrong direction. Supporting static analysis =
may be attractive, but before any such static analyzer is built, we cannot =
determine what support is needed and if it is helpful at all.<br></div></di=
v>

<p></p>

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

<p></p>

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

.