Tomasz Sowiński wrote:
I like removing "body". But maybe we can make contracts a bit nicer by removing
braces if the contract contains only one statement:
void foo()
in assert(something);
out assert(something_else);
{ ... }
would that be ambiguous to the compiler?
Probably not, but I'm not
On Thu, Apr 9, 2009 at 2:56 AM, Don wrote:
> Jarrett Billingsley wrote:
>>
>> On Wed, Apr 8, 2009 at 10:59 PM, Christopher Wright
>> wrote:
>>>
>>> Or just your style guide. But even if you can demonstrate significant
>>> benefits (and I don't see any benefits, really), inertia is against you.
>>
Stewart Gordon Wrote:
> Finally, a counter-argument with which I agree. Moreover, having in/out
> contracts as part of the function body suggests that they are part of
> what is overridden. But the language doesn't quite work like that.
I thought, they're overriden.
Jarrett Billingsley Wrote:
> OK, then what about:
>
> void foo()
> in { ... }
> out { ... }
> { ... }
>
> the 'body' keyword is completely arbitrary. There is no ambiguity here.
>
> Also, I almost never use contracts because of their verbosity. It's
> much shorter - and functionally equivalen
Michel Fortin wrote:
I believe the syntax should make the contracts part of the function
signature, not part of the function body, because contracts are about
expressing the function's interface. So I disagree with your proposed
syntax which puts the contracts as part of the body.
Finally,
Danny Wilson wrote:
2 x Fifthed + 1 = Eleventhed!
Don't you mean
2 × Fifthed + Firsted = Eleventhed
?
Stewart.
Jarrett Billingsley wrote:
On Wed, Apr 8, 2009 at 10:59 PM, Christopher Wright wrote:
Or just your style guide. But even if you can demonstrate significant
benefits (and I don't see any benefits, really), inertia is against you. I
don't think Walter would change it for anything but extreme prov
On Wed, Apr 8, 2009 at 10:59 PM, Christopher Wright wrote:
>
> Or just your style guide. But even if you can demonstrate significant
> benefits (and I don't see any benefits, really), inertia is against you. I
> don't think Walter would change it for anything but extreme provocation.
Are you sugg
Jarrett Billingsley wrote:
On Wed, Apr 8, 2009 at 6:38 PM, Christopher Wright wrote:
Then take this example:
void foo(int i)
{
if (i < 0) return;
in { assert (i != -1; }
}
This is confusing.
There's a simple solution: define the function body grammar to only
allow in{} and out{} blocks
On 2009-04-08 10:46:19 -0400, bearophile said:
I like contract programming, it helps me avoid bugs. This is an example
from the docs:
long squareRoot(long x)
in {
assert(x >= 0);
}
out (result) {
assert((result * result) <= x && (result+1) * (result+1) >= x);
2 x Fifthed + 1 = Eleventhed!
Op Wed, 08 Apr 2009 20:51:17 +0200 schreef Alexander Pánek
:
Fifthed. How about using bigfloat for that?
Jarrett Billingsley wrote:
On Wed, Apr 8, 2009 at 4:51 PM, Christopher Wright wrote:
No. This proposed syntax change is quite misleading. Contracts cannot access
the function's local variables, but it looks like they can. Contracts are
executed at particular times, but that syntax makes them lo
On Wed, Apr 8, 2009 at 6:38 PM, Christopher Wright wrote:
> Then take this example:
>
> void foo(int i)
> {
> if (i < 0) return;
> in { assert (i != -1; }
> }
>
> This is confusing.
There's a simple solution: define the function body grammar to only
allow in{} and out{} blocks at the beginni
Denis Koroskin wrote:
On Thu, 09 Apr 2009 00:51:49 +0400, Christopher Wright
wrote:
bearophile wrote:
But isn't a syntax like the following better? To me it looks more
logic, because in{} and out(){} are part of the function, and there's
no need of a special syntax for the body (and the 'bo
On Wed, Apr 8, 2009 at 5:32 PM, Frits van Bommel
wrote:
>
> Not technically true -- contract can contain more than raw asserts.
> For example, it might contain a non-trivial loop (such as a foreach which
> calls a virtual opApply) which may be hard for the compiler to optimize out
> even if it can
Jarrett Billingsley wrote:
On Wed, Apr 8, 2009 at 4:51 PM, Christopher Wright wrote:
No. This proposed syntax change is quite misleading. Contracts cannot access
the function's local variables, but it looks like they can. Contracts are
executed at particular times, but that syntax makes them lo
On Thu, 09 Apr 2009 00:51:49 +0400, Christopher Wright
wrote:
bearophile wrote:
But isn't a syntax like the following better? To me it looks more
logic, because in{} and out(){} are part of the function, and there's
no need of a special syntax for the body (and the 'body' keyword):
long
On Wed, Apr 8, 2009 at 4:51 PM, Christopher Wright wrote:
>
> No. This proposed syntax change is quite misleading. Contracts cannot access
> the function's local variables, but it looks like they can. Contracts are
> executed at particular times, but that syntax makes them look like they
> execute
On Wed, 08 Apr 2009 10:46:19 -0400, bearophile wrote:
> But isn't a syntax like the following better? To me it looks more logic,
> because in{} and out(){} are part of the function, and there's no need
> of a special syntax for the body (and the 'body' keyword):
Yes!
I've never been happen with
Christopher Wright:
>Contracts cannot access the function's local variables, but it looks like they
>can.<
You are right, thank you.
Bye,
bearophile
bearophile wrote:
But isn't a syntax like the following better? To me it looks more logic,
because in{} and out(){} are part of the function, and there's no need of a
special syntax for the body (and the 'body' keyword):
long squareRoot(long x) {
in {
assert(x >= 0);
}
out
dsimcha wrote:
while(oldContractSyntaxSucks) { // Currently evaluates to true.
vote++;
}
And always will do :D
Proposed updated code:
while(currentContractSyntaxSucks) { // Currently evaluates to true.
vote++;
}
complainAboutSomethingElse();
== Quote from Nick Sabalausky (a...@a.a)'s article
> "bearophile" wrote in message
> news:gridbr$mv...@digitalmars.com...
> >I like contract programming, it helps me avoid bugs. This is an example
> >from the docs:
> >
> > long squareRoot(long x)
> >in {
> >assert(x >= 0);
> >}
> >
Jarrett Billingsley wrote:
Wed, Apr 8, 2009 at 1:02 PM, Denis Koroskin <2kor...@gmail.com> wrote:
On Wed, 08 Apr 2009 20:01:46 +0400, Kagamin wrote:
Don Wrote:
I agree, the 'body' keyword is the most useless thing in the language. I
find it makes functions much harder to read.
I hate my bo
Jarrett Billingsley wrote:
Wed, Apr 8, 2009 at 1:02 PM, Denis Koroskin <2kor...@gmail.com> wrote:
On Wed, 08 Apr 2009 20:01:46 +0400, Kagamin wrote:
Don Wrote:
I agree, the 'body' keyword is the most useless thing in the language. I
find it makes functions much harder to read.
I hate my bo
Wed, Apr 8, 2009 at 1:02 PM, Denis Koroskin <2kor...@gmail.com> wrote:
> On Wed, 08 Apr 2009 20:01:46 +0400, Kagamin wrote:
>
>> Don Wrote:
>>
>>> I agree, the 'body' keyword is the most useless thing in the language. I
>>> find it makes functions much harder to read.
>>> I hate my body.
>>
>> I
More agreement here.
--bb
On Thu, Apr 9, 2009 at 2:41 AM, Nick Sabalausky wrote:
> "bearophile" wrote in message
> news:gridbr$mv...@digitalmars.com...
>>I like contract programming, it helps me avoid bugs. This is an example
>>from the docs:
>>
>> long squareRoot(long x)
>> in {
>> a
"bearophile" wrote in message
news:gridbr$mv...@digitalmars.com...
>I like contract programming, it helps me avoid bugs. This is an example
>from the docs:
>
> long squareRoot(long x)
>in {
>assert(x >= 0);
>}
>
>out (result) {
>assert((result * result) <= x && (resul
On Wed, 08 Apr 2009 20:01:46 +0400, Kagamin wrote:
Don Wrote:
I agree, the 'body' keyword is the most useless thing in the language. I
find it makes functions much harder to read.
I hate my body.
I second this.
Thirded.
Don Wrote:
> I agree, the 'body' keyword is the most useless thing in the language. I
> find it makes functions much harder to read.
> I hate my body.
I second this.
bearophile wrote:
I like contract programming, it helps me avoid bugs. This is an example from
the docs:
long squareRoot(long x)
in {
assert(x >= 0);
}
out (result) {
assert((result * result) <= x && (result+1) * (result+1) >= x);
}
body {
return ca
31 matches
Mail list logo
