08-Feb-2013 15:25, monarch_dodra пишет:
> On Thursday, 7 February 2013 at 22:36:53 UTC, Andrei Alexandrescu wrote:
>> On 2/7/13 5:27 PM, Vladimir Panteleev wrote:
>>> On Thursday, 7 February 2013 at 22:22:09 UTC, Stewart Gordon wrote:
>>>> This is what I've found: Validity checking is done in an in contract!
>>>
>>> I've ran into the same problem with std.base64. DbC doesn't seem to be a
>>> generally well-understood concept.
>>
>> That's why TDPL dedicates a whole chapter to it (separate from error
>> handling!). Apparently that didn't make a dent in the Universe :o).
>>
>> Andrei
>
> "in" and "out" contracts themselves are flawed in D in any case, given
> they are part of the "called" code, as opposed to "caller" code.
>

+111

> This makes them absolutely no different than an assert.
>
> The problem is that an assert is "internal" validation, whereas an
> "in"/"out" is supposed to be a handshake between the caller/callee.
>
> If I write an "sqrt" function, and document it as "Please, only give me
> positive numbers", and then write a contract for it, and then compile my
> lib in release, the caller will have no way of "signing" my contract.
>
> He'll call my sqrt with negative numbers, and the in will never get
> called, and sqrt will crash horribly.


-- 
Dmitry Olshansky

On Friday, 8 February 2013 at 11:06:56 UTC, Jacob Carlborg wrote:
> On 2013-02-07 23:35, Nick Sabalausky wrote:
>> std.xml itself is known to be absurd. I haven't used it myself,
>> but there's been a general consensus for years that it needs a complete
>> rewrite. Attempts have been started, but nobody's finished one,
>> AFAIK. You could try the XML module in Tango, it's supposed to be
>> ridiculously fast.
>
> It is fast, but it doesn't perform any validations. I have no idea what happens if pass invalid XML to it.

The fact is that it isn't fast at the end. Tango.xml beat it pretty badly.

On Friday, 8 February 2013 at 11:25:07 UTC, monarch_dodra wrote:
> "in" and "out" contracts themselves are flawed in D in any case, given they are part of the "called" code, as opposed to "caller" code.
>
> This makes them absolutely no different than an assert.
>
> The problem is that an assert is "internal" validation, whereas an "in"/"out" is supposed to be a handshake between the caller/callee.

Isn't it exactly how contracts are supposed to work? They are neither error handling tools, nor handshake - more like tools to verify interconnections between different inner parts of program stay sane. For example, in web application you would like to escape user input only once, upon receiving it, and it makes sense to not waste cycles on verifying it is actually escaped down the code path. But adding a contract to make sure someone does not use that library function on a raw input by accident - makes perfect sense. Of course, contracts shine only if some debug-mode testing is in place during development process but right now they do behave in D exactly how I would have supposed.

On 2/8/13 6:25 AM, monarch_dodra wrote:
> "in" and "out" contracts themselves are flawed in D in any case, given
> they are part of the "called" code, as opposed to "caller" code.

What would be the right design and implementation?

> This makes them absolutely no different than an assert.
>
> The problem is that an assert is "internal" validation, whereas an
> "in"/"out" is supposed to be a handshake between the caller/callee.
>
> If I write an "sqrt" function, and document it as "Please, only give me
> positive numbers", and then write a contract for it, and then compile my
> lib in release, the caller will have no way of "signing" my contract.

I don't think std.math.sqrt should validate its input using a contract.

> He'll call my sqrt with negative numbers, and the in will never get
> called, and sqrt will crash horribly.

It'll return NaN.

> A *BLATANT* example of this limitation is slice operations: They have an
> in contract stating that the slices need to be the same length. However,
> this contract will never ever get run, for anyone, because druntime is
> built and distributed in release. Long story short, even if I compile in
> debug, the code will silently run erroneously.
>
> http://d.puremagic.com/issues/show_bug.cgi?id=8650

That druntime uses a contract to verify length in slice is an antipattern. It should use a sheer test and throw.

> Please see also:
> http://d.puremagic.com/issues/show_bug.cgi?id=4720

This is legit. We should have a way to separate contracts from body in the general case.

> http://d.puremagic.com/issues/show_bug.cgi?id=6549

This, too, is legit.

> And finally, this old thread about the subject, which kind of fell into
> darkness:
> http://forum.dlang.org/thread/jamrtmgozgtswdadeocg@forum.dlang.org

Yeah, makes sense. I don't think we should put contracts on the front burner. For whatever reason, people don't use contracts or they misuse them. I have no idea why. The obvious argument is that people would use contracts if this or that bug were fixed, but there's past evidence suggesting the contrary.


Andrei

On 08/02/2013 11:25, monarch_dodra wrote:
<snip>
> "in" and "out" contracts themselves are flawed in D in any case, given they are part of
> the "called" code, as opposed to "caller" code.
<snip>

I think you'll find that this is an implementation issue, rather than a language issue.

It's been discussed many times over, but it seems that for some reason it's still too controversial to get a fix any time soon.  Meanwhile, I've filed these to try and soften the blow:

http://d.puremagic.com/issues/show_bug.cgi?id=9482
http://d.puremagic.com/issues/show_bug.cgi?id=9483

Stewart.

Andrei Alexandrescu:

> I don't think std.math.sqrt should validate its input using a contract.

Why not? Returning a NaN is an option. But in a language that supports contracts, its precondition should only accept non-negative inputs.


> That druntime uses a contract to verify length in slice is an antipattern.

Why?


> I don't think we should put contracts on the front burner.

Why? (And I don't agree).


>That's why TDPL dedicates a whole chapter to it (separate from error
handling!). Apparently that didn't make a dent in the Universe :o).<

Instead of not putting contracts on the front burner, I suggest to think about the causes, find some of them, and then try to fix the causes.


> For whatever reason, people don't use contracts or they misuse them. I have no idea why. The obvious argument is that people would use contracts if this or that bug were fixed, but there's past evidence suggesting the contrary.

I am using D contracts in my code. I think there are three or more reasons for people not using D contracts a lot:
- C/C++/Python/Java programmers don't know much about contract programming. They look like improved asserts, while they require a bit different mindset. Learning a different mindset requires time and work. This is an important point but I think this isn't the most important one.
- D contracts miss some important parts, the pre-state is one of them. Other problems are present (as they say "move in contract checking to the caller side").
- I think Phobos contracts get removed. This reduces their usefulness. If you have a feature X in your language and you aren't using it in your standard library, then a bit of redesign is needed.
- D is used a system language, where often programmers think of asserts as things present only in debug builds. But maybe contracts should have a different compiler switch to be stripped away (http://d.puremagic.com/issues/show_bug.cgi?id=9482 ).

I also think it's good to reduce the usage of enforce() in contracts, because I think it doesn't help the cause of D Contracts. I think well implemented Contracts don't need exceptions.

Bye,
bearophile

Stewart Gordon has opened this ER (worth voting for):

http://d.puremagic.com/issues/show_bug.cgi?id=9483

Bye,
bearophile

On Friday, 8 February 2013 at 13:33:43 UTC, bearophile wrote:
> Andrei Alexandrescu:
>
>> I don't think std.math.sqrt should validate its input using a contract.
>
> Why not? Returning a NaN is an option. But in a language that supports contracts, its precondition should only accept non-negative inputs.
>
> Bye,
> bearophile

Passing a negative number to sqrt is something that could well be an expected event in release code that works with real data.

A Nan is a convenient way of marking bad data (and anything calculated from that data) as being invalid without having to set up an exception framework that does the same job explicitly and inefficiently.

If sqrt used contracts, then that would make debug mode useless to a lot of data analysis programs that are designed (sensibly) to use NaNs.

On 2013-02-08 14:59, bearophile wrote:
> Stewart Gordon has opened this ER (worth voting for):
> http://d.puremagic.com/issues/show_bug.cgi?id=9483

A good proposal now, when it's the callee that does contract validation.
And easier to do than "move in contract checking to the caller side".

On 02/08/2013 04:54 AM, Andrei Alexandrescu wrote:

>> If I write an "sqrt" function, and document it as "Please, only give me
>> positive numbers", and then write a contract for it, and then compile my
>> lib in release, the caller will have no way of "signing" my contract.
>
> I don't think std.math.sqrt should validate its input using a contract.

As the module writer, I don't know whether my function is going to be used as an "API function" or as an "internal function" in somebody else's module.

In the former case, I would like my checks to be enforce() calls so that I don't produce incorrect results.

However, in the latter case, I would like my checks to be in an 'in' block so that when my client compiles in release mode, my checks would disappear. This is under the assumption that my client has tested their code and they are sure that all of the contracts are met. There is no need for them to waste time running the checks unnecessarily.

Ali