On Monday, 26 August 2013 at 06:14:02 UTC, Ali Çehreli wrote:
On 08/25/2013 05:16 AM, deadalnix wrote:
> The problem is that invariant are checked at the
> beginning/end on public function calls. As a consequence, it
> is impossible to use any public
> method in an invariant.
That's a very i
On 8/3/2012 1:48 PM, Alex Rønne Petersen wrote:
The problem here is that making invariants const *now* means that using
them in conjunction with Phobos code becomes next to impossible. Casting
away const will become common practice, and that ain't exactly the way
we want to go. :/
Understood an
On 8/3/2012 1:14 PM, Paulo Pinto wrote:
Personally I feel D's contracts are still a bit off of what Eiffel,
.NET and Ada 2012 offer.
On 8/3/2012 1:01 PM, Alex Rønne Petersen wrote:
So what if, for whatever reason, the invariant needs to track and
maintain some state in order to catch some ki
On 8/3/2012 12:40 PM, bearophile wrote:
H. S. Teoh:
IMO, if you need to be changing stuff inside invariants, then you're
using it wrong. Invariants are intended to verify program logic, not
to do things like altering object state. The point is to be able to
compile with invariant code turned of
On 1/19/2012 4:08 PM, Jonathan M Davis wrote:
On Thursday, January 19, 2012 17:29:28 bearophile wrote:
If I am mistaken please I'd like to know why the current design is better
(or maybe why it's just equally good). Thank you :-)
Honestly, I don't think that the order is all that critical, sin
I don't get it -- why is this even necessary? Please don't answer here.
Swing over to D.learn, where I am starting an "assert(obj) is a mystery"
thread...
...because answers that start with "because..." belong in a "learn"
newsgroup.
Thanks in advance.
-- Davidson
On 11/8/2011 2:35 PM, A
On 10/29/2011 8:26 PM, bearophile wrote:
The only reason to have an 'out(result)' form is to declare that we
intend to use the magic 'result' symbol in the post-condition testing.
This is not true. Currently 'result' has nothing magic, it's just a variable
name, you are free to change it:
Ah
On 10/28/2011 5:10 AM, kennytm wrote:
Davidson Corry wrote:
> ...it occurred to me the other day that we could write contracts as
>
> void foo(T t)
> {
> scope(in) {
>// pre-condition contracts
> }
On 10/27/2011 9:04 PM, bearophile wrote:
> Agreed. In fact, it occurred to me the other day that we could write
> contracts as
>
>void foo(T t)
>{
>scope(in) {
> // pre-condition contracts
>}
>scope(out) {
> //
On 10/27/2011 2:12 PM, Timon Gehr wrote:
Yes, this design has indeed a keyword-issue that your proposal has not.
I am all for not making it a keyword. The 'body' keyword imho should be
removed too, there is only one place in the grammar where it is ever
needed (and there it is completely redundan
I want to point out (quick, before someone else does!) that the
lowerings I have suggested for old! elsewhere in this thread are naïve.
In the presence of inheritance, interface contracts, and/or multiple
subtyping, things can get notably trickier.
That said,
1) I don't think it affects the ut
Oooh! Now we're getting somewhere! You and bearophile have opened my eyes.
On 10/27/2011 1:17 AM, Timon Gehr wrote:
> ...your example shows an extreme case and from that you
> conclude a general statement. That almost never works.
I merely intended to show that my proposed syntax could *handle*
On 10/26/2011 5:19 PM, bearophile wrote:
out(result, X preX = exprX, Y preY = exprY) { //<== prestate
I'd like something lighter, syntax-wise, where the is no need to state new and
old names and types:
>out(result, exprX, exprY) {
And then the compiler lets you access in the
(continuing a thread from D.learn)
Eiffel supports an 'old' construct in post-conditions. For example, an
Add method of a Bag class (generic collection container) might verify
that exactly one element was added to the collection, not zero and not
more than one:
Add(newItem : T) is
14 matches
Mail list logo
