On 2/5/15 5:47 AM, Mike Parker wrote:
> On 2/5/2015 5:22 PM, Jonathan M Davis via Digitalmars-d wrote:
>> On Thursday, February 05, 2015 08:13:32 eles via Digitalmars-d wrote:
>>> On Thursday, 5 February 2015 at 06:55:09 UTC, Vlad Levenfeld
>>> wrote:
>>>> On Thursday, 5 February 2015 at 06:51:35 UTC, Vlad Levenfeld
>>>> wrote:
>>>>> I could care less
>>>>
>>>> Er, stupid but unfortunately common american english idiom. For
>>>
>>> Thanks. I was firmly convinced that's a typo...
>>
>> No. It's just a frustratingly common mistake - like saying "for all
>> intensive purposes" instead of "for all intents and purposes."
>> Unfortunately, many folks couldn't care less about getting it right...
>>
>> - Jonathan M Davis
>>
>
> I can't phantom that!

I think we should return to the topic at hand irregardless. -- Andrei

On Thursday, 5 February 2015 at 07:06:31 UTC, deadalnix wrote:
> On Thursday, 5 February 2015 at 04:36:39 UTC, Zach the Mystic wrote:
>> I have an idea. Treat all assert statements which come before the first non-assert statement as part of the 'in' contract. I'm not saying the compiler has to generate a whole 'in' function, but these asserts can be internally tagged to behave *as if* in an 'in' contract. That solves the tooling problem and the too-much-code problem, no?
>
> No. There is no point of screwing up the language because an arbitrary choice of formating is taking an absurd amount of vertical space.

Screwing up the language? I'd be willing to accept your position if I could think of any possible instance in which:

T myFunc()
  assert(xxx);
  assert(yyy);
  doStuff();
}

... were not intended to be semantically equivalent to:

T myFunc()
in {
  assert(xxx);
  assert(yyy);
}
body {
  doStuff();
}

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.

On 2/5/15 2:55 AM, eles wrote:
> On Thursday, 5 February 2015 at 10:51:32 UTC, eles wrote:
>> On Thursday, 5 February 2015 at 09:02:05 UTC, deadalnix wrote:
>>> On Thursday, 5 February 2015 at 07:28:36 UTC, Paulo Pinto wrote:
>>>> I miss the point about in.
>>>>
>>>> DbC as presentend by Eiffel and adopted in .NET, Ada among others,
>>>> the complete contract is on the  callee.
>>>>
>>>> It doesn't make sense otherwise.
>>>
>>> There was a huge discussion here:
>>> https://issues.dlang.org/show_bug.cgi?id=6857
>>
>> Wow. Amazing discussion.
>
> But it ends with:
>
> "Andrei Alexandrescu 2013-01-10 09:14:02 UTC
> @Walter: would you preapprove this?"
>
> Well, we are now 2 years (and some) later.

It has been preapproved. The challenge now is implementing it. -- Andrei

On 2/5/15 9:31 AM, Andrei Alexandrescu wrote:
> On 2/5/15 2:55 AM, eles wrote:
>> On Thursday, 5 February 2015 at 10:51:32 UTC, eles wrote:
>>> On Thursday, 5 February 2015 at 09:02:05 UTC, deadalnix wrote:
>>>> On Thursday, 5 February 2015 at 07:28:36 UTC, Paulo Pinto wrote:
>>>>> I miss the point about in.
>>>>>
>>>>> DbC as presentend by Eiffel and adopted in .NET, Ada among others,
>>>>> the complete contract is on the  callee.
>>>>>
>>>>> It doesn't make sense otherwise.
>>>>
>>>> There was a huge discussion here:
>>>> https://issues.dlang.org/show_bug.cgi?id=6857
>>>
>>> Wow. Amazing discussion.
>>
>> But it ends with:
>>
>> "Andrei Alexandrescu 2013-01-10 09:14:02 UTC
>> @Walter: would you preapprove this?"
>>
>> Well, we are now 2 years (and some) later.
>
> It has been preapproved. The challenge now is implementing it. -- Andrei

Better put: it had been preapproved back in Jan 2013 and is still looking for someone to fix it. -- Andrei

On Thursday, 5 February 2015 at 11:05:42 UTC, Paulo  Pinto wrote:
> On Thursday, 5 February 2015 at 10:09:34 UTC, deadalnix wrote:
>> On Thursday, 5 February 2015 at 09:33:12 UTC, Paulo  Pinto wrote:
>>> So the caller can break the contract without any consideration for what values the input arguments are valid?!
>>>
>>> There is a reason why the industry at large has adopted the Eiffel way.
>>>
>>
>> Yes, it is called cargo cult.
>
> I am out.

To be frankly brutal, you were never in. You presented no argument.

On Thursday, 5 February 2015 at 17:32:23 UTC, deadalnix wrote:
> On Thursday, 5 February 2015 at 11:05:42 UTC, Paulo  Pinto wrote:
>> On Thursday, 5 February 2015 at 10:09:34 UTC, deadalnix wrote:
>>> On Thursday, 5 February 2015 at 09:33:12 UTC, Paulo  Pinto wrote:
>>>> So the caller can break the contract without any consideration for what values the input arguments are valid?!
>>>>
>>>> There is a reason why the industry at large has adopted the Eiffel way.
>>>>
>>>
>>> Yes, it is called cargo cult.
>>
>> I am out.
>
> To be frankly brutal, you were never in. You presented no argument.

I did, by stating that the way Eiffel does is how it is supposed to be.

Also mentioned that by giving the callers control over pre-conditions is breaking the notion of what Design by Contract stands for. If the caller can disable pre-conditions of the callee, then the premisses of Design by Contract just go out of the window.

I was dry with my statement, because by calling the verification industry as cargo cultists, I could only depreend no argument on my side would change your opinion.

As far as I can tell, D in production doesn't even reach 1% of production systems out there coded in Eiffel, Ada 2012, .NET Code Contracts, Spec# and Dafny uses at MSR, Dbc at NASA, Dbc at Lockheed Martin and so on, wherever it is used.

Yet, here goes the discussion against what production quality systems have been delivering because they are all wrong and its developers are plain cargo cultists.

Anyway, as a simple D dabbler I should learn to keep quiet, as I am just adding noise to the NG.

--
Paulo

On 2/5/15 11:19 AM, Paulo Pinto wrote:
> I did, by stating that the way Eiffel does is how it is supposed to be.

That issue reveals that Eiffel essentially contradicts directly its creators' book. -- Andrei

On Thursday, 5 February 2015 at 19:19:43 UTC, Paulo Pinto wrote:
>> To be frankly brutal, you were never in. You presented no argument.
>
> I did, by stating that the way Eiffel does is how it is supposed to be.
>

In the links that were provided to you, you'll see one instance of Eiffel's designer saying that this was done like this at first for ease of implementation and then it stated like this for historical reason, and that the sensible thing to do is to put the check in the caller.

No, if you want to say that Eiffel is the way it should, while even its creator think this is not the case, you have to substantiate. Saying that Eiffel do it in some way is certainly a fact, but not an argument.

> I was dry with my statement, because by calling the verification industry as cargo cultists, I could only depreend no argument on my side would change your opinion.
>

In fact this is very possible to change my opinion. If you read the bug report, you'll notice that I'm defending a position similar to yours at first.

Considering that someone who contradict you cannot be convinced anyway is a lazy. I'm not changing my position because no new argument have been presented.

On 2/5/2015 12:22 AM, Jonathan M Davis via Digitalmars-d wrote:
> No. It's just a frustratingly common mistake - like saying "for all
> intensive purposes" instead of "for all intents and purposes."

What? I thought it was "for all infants and porpoises"!

On Thu, Feb 05, 2015 at 12:03:29PM -0800, Walter Bright via Digitalmars-d wrote:
> On 2/5/2015 12:22 AM, Jonathan M Davis via Digitalmars-d wrote:
> >No. It's just a frustratingly common mistake - like saying "for all intensive purposes" instead of "for all intents and purposes."
> 
> What? I thought it was "for all infants and porpoises"!

What, what? For elephants and porpoises? I thought this was a programming language forum; I must have subscribed to a zoo magazine by mistake!


T

-- 
Programming is not just an act of telling a computer what to do: it is also an act of telling other programmers what you wished the computer to do. Both are important, and the latter deserves care. -- Andrew Morton