On Fri, 06 Feb 2015 15:59:04 +0000, Chris wrote:

> Hm. But the compiler can check, if the signature is ok. E.g.

"wtf, compiler, are you making fun of me? you KNOW what i mean, yet you insisting that i have to please you... ah, fsck it! that shitty feature never worth it anyway."

  auto foo (int n) { ... }
  auto foo (int n, int m) { ... }

  // i'm soooo sleepy
  contract {
    auto foo (int n) {
      ...
    }
    auto foo (int n, int m) {
      ...check for foo(n) that i copipasted here
      ...and completely forgot about it, 'cause
      ...that "contract" clause is sooooo far away
      ...from the function itself...
    }
  }

and so on.

> I like it, if things can be put aside in blocks, like unittest or debug.

unittest and debug blocks are not parts of function contract, that's why they can be separated. they are merely *checks*, not *prerequisites*.

On Friday, 6 February 2015 at 16:22:00 UTC, ketmar wrote:
> On Fri, 06 Feb 2015 15:59:04 +0000, Chris wrote:
>
>> Hm. But the compiler can check, if the signature is ok. E.g.
>
> "wtf, compiler, are you making fun of me? you KNOW what i mean, yet you
> insisting that i have to please you... ah, fsck it! that shitty feature
> never worth it anyway."
>
>   auto foo (int n) { ... }
>   auto foo (int n, int m) { ... }
>
>   // i'm soooo sleepy
>   contract {
>     auto foo (int n) {
>       ...
>     }
>     auto foo (int n, int m) {
>       ...check for foo(n) that i copipasted here
>       ...and completely forgot about it, 'cause
>       ...that "contract" clause is sooooo far away
>       ...from the function itself...
>     }
>   }
>
> and so on.
>
>> I like it, if things can be put aside in blocks, like unittest or debug.
>
> unittest and debug blocks are not parts of function contract, that's why
> they can be separated. they are merely *checks*, not *prerequisites*.

I would like to try, if it is really so bad. If laziness is an argument against it, it also applies to in {} and out {}, doesn't it?

On Fri, 06 Feb 2015 19:09:47 +0000, Chris wrote:

> I would like to try, if it is really so bad. If laziness is an argument against it, it also applies to in {} and out {}, doesn't it?

it's not lazyness per se, it's inconsistency and lack of usability. sure, you are free to try, but i bet that you simply waste some time with it. i have nothing personal against this (i simply don't care).

On Thursday, 5 February 2015 at 00:37:31 UTC, Adam D. Ruppe wrote:
> On Thursday, 5 February 2015 at 00:35:50 UTC, bearophile wrote:
>> Contracts can be read by tools, and they are part of the function signature. Contracts should be encouraged and increased, not discouraged.
>
>
> I agree. Moreover, if the assert fails in the contract, in theory, we can point the error at the user's code. An assert inside the function is the function's responsibility. An assert in an in contract is the caller's responsibility. They're semantically different (even if dmd treats them the same way)

FWIW (only reading this discussion now, sorry if it has already been stated by someone else), this was also talked about at the Berlin meeting, with the same conclusion. IIRC someone was disappointed that failure on the caller's side to pass correct parameters to a library with contracts caused AssertErrors to be thrown inside the callee, making it seem it was the library's fault.

On Thursday, 5 February 2015 at 16:34:38 UTC, Zach the Mystic wrote:
> Can you name one, or even imagine one? Bear in mind people like Andrei and myself do not like to read or write the later form and will use it much less, regardless of benefit.

Daniel Murphy has (function stubs with `assert(0)`), here:

http://forum.dlang.org/thread/maud7e$1j3u$1@digitalmars.com?page=7#post-mavf13:24130j:241:40digitalmars.com

On Sunday, 8 February 2015 at 13:03:28 UTC, Marc Schütz wrote:
> On Thursday, 5 February 2015 at 16:34:38 UTC, Zach the Mystic wrote:
>> Can you name one, or even imagine one? Bear in mind people like Andrei and myself do not like to read or write the later form and will use it much less, regardless of benefit.
>
> Daniel Murphy has (function stubs with `assert(0)`), here:
>
> http://forum.dlang.org/thread/maud7e$1j3u$1@digitalmars.com?page=7#post-mavf13:24130j:241:40digitalmars.com

assert(0) is a special case, and could be easily identified as such. My attitude would be to try to find a way to make this work, according to the principle that the common case should be easy, and the rarer case possible. The difference only applies to what the user is told about when the assert fails, and not the execution semantics themselves - so it's really not "screwing up the language", unless I'm wrong.

Also, in Daniel Murphy's example:

void func(int x)
in
{
   assert(x > 6); // If this assert fails the caller was incorrect
}
body
{
   assert(x > 7); // If this assert fails then 'func' has a bug.
}

I don't know how the second assert could men somethign different from the first. If you assert (anything but assert(0)) first thing, you certainly are not checking for bugs *within* the function - you're checking for entry conditions. So the question is whether the practical difference between the two asserts above is sufficient to prevent applying the syntax sugar. I personally can live with it either way (I can handle being told the the function failed when it was really the caller that failed), but it's a judgment call. I mean, this thread was literally called "Another idiom I wish were gone from phobos/druntime." I don't expect it is the last time someone will complain about it.

"Zach the Mystic"  wrote in message news:qxtyqdeewrjurmwhksbj@forum.dlang.org...

> I don't know how the second assert could men somethign different from the first. If you assert (anything but assert(0)) first thing, you certainly are not checking for bugs *within* the function - you're checking for entry conditions. So the question is whether the practical difference between the two asserts above is sufficient to prevent applying the syntax sugar. I personally can live with it either way (I can handle being told the the function failed when it was really the caller that failed), but it's a judgment call. I mean, this thread was literally called "Another idiom I wish were gone from phobos/druntime." I don't expect it is the last time someone will complain about it.

Here's one:

struct S
{
private:
   static int instanceCount;

...

public:
   void func(int x)
   in
   {
       assert(x >= 0, "can't call func with negative x");
   }
   body
   {
       assert(instanceCount > 0);
   }
}

The first assert checks something the caller has control over, the second assert is a sanity check, and if it fails it's not an error in the caller.

Anyway, IMO there is zero chance of this making it into the language and you're wasting your energy. 

On Sunday, 8 February 2015 at 17:12:20 UTC, Daniel Murphy wrote:
> "Zach the Mystic"  wrote in message news:qxtyqdeewrjurmwhksbj@forum.dlang.org...
>
>> I don't know how the second assert could men somethign different from the first. If you assert (anything but assert(0)) first thing, you certainly are not checking for bugs *within* the function - you're checking for entry conditions. So the question is whether the practical difference between the two asserts above is sufficient to prevent applying the syntax sugar. I personally can live with it either way (I can handle being told the the function failed when it was really the caller that failed), but it's a judgment call. I mean, this thread was literally called "Another idiom I wish were gone from phobos/druntime." I don't expect it is the last time someone will complain about it.
>
> Here's one:
>
> struct S
> {
> private:
>    static int instanceCount;
>
> ...
>
> public:
>    void func(int x)
>    in
>    {
>        assert(x >= 0, "can't call func with negative x");
>    }
>    body
>    {
>        assert(instanceCount > 0);
>    }
> }
>
> The first assert checks something the caller has control over, the second assert is a sanity check, and if it fails it's not an error in the caller.

Well, okay. This is a case where there is a slight practical difference. In the spirit of keeping the rare case possible, I would suggest:

   body
   {
       {} // reject in-contract assert
       assert(instanceCount > 0);
   }

> Anyway, IMO there is zero chance of this making it into the language and you're wasting your energy.

That's disappointing, but I didn't waste my energy. I realized there's validity to both sides of this argument (bulky contracts vs. accurate errors), and instead of choosing a side, I tried to come up with the biggest total win for both sides. I think my solution is a 80-90% win for both sides, which is better than 100-0% for just one. If it gets rejected for some other reason, so be it. I'm trying to help, here!