On Saturday, 2 August 2014 at 06:01:52 UTC, Timon Gehr wrote:
> On 08/02/2014 07:56 AM, eles wrote:
>> On Friday, 1 August 2014 at 20:22:39 UTC, Tofu Ninja wrote:
>>> On Friday, 1 August 2014 at 20:16:29 UTC, eles wrote:

> It's part of the language standard. The compiler can make as much use of it as possible while still conforming to the spec.

If you put it like that, then you could put *everything* into the library. Classes were once defined as a layer over C and they could be defined as standard. Still, the concept went into the compiler.

What will the optimizer do if you don't link against the standard library?

On 08/02/2014 07:35 AM, Walter Bright wrote:
> On 8/1/2014 7:13 PM, David Bregman wrote:
>> OK, I think I have an idea how to be more convincing (I wish I'd
>> thought of this
>> earlier):
>>
>> is this
>> http://www.cplusplus.com/reference/cassert/assert/
>>
>> the same as this?
>> http://msdn.microsoft.com/en-us/library/1b3fsfxw.aspx
>>
>> can you see the difference now?
>
> What I see is Microsoft attempting to bring D's assert semantics into
> C++. :-)
>

Note, regardless of the validity or invalidity of your point:


                You evaded the question.


> As I've mentioned before, there is inexorable pressure for this to
> happen, and it will happen.

And when it does happen, criminals will rejoice, right?

On 08/02/2014 08:04 AM, eles wrote:
> On Saturday, 2 August 2014 at 06:01:52 UTC, Timon Gehr wrote:
>> On 08/02/2014 07:56 AM, eles wrote:
>>> On Friday, 1 August 2014 at 20:22:39 UTC, Tofu Ninja wrote:
>>>> On Friday, 1 August 2014 at 20:16:29 UTC, eles wrote:
>
>> It's part of the language standard. The compiler can make as much use
>> of it as possible while still conforming to the spec.
>
> If you put it like that, then you could put *everything* into the
> library. Classes were once defined as a layer over C and they could be
> defined as standard. Still, the concept went into the compiler.
>
> What will the optimizer do if you don't link against the standard library?

IIRC there are bits of the standard that allow the optimizer to assume that you will, but don't take my word for it.

On 8/1/2014 11:08 PM, Timon Gehr wrote:
> You evaded the question.

Those have been posted here before, and I responded in detail to them, more than once.

I have nothing new to say about it.

"Jonathan M Davis"  wrote in message news:zbkvnbibbmcfwhjvmhau@forum.dlang.org...

> > IMO the correct solution is for the compiler to insert preconditions at the calling site, rather than the callee.
>
> If we had that, I'd actually start using in blocks. As it is, I think that they're useless except when inheritance is involved, and they're more verbose than just putting the assertions at the top of the function, so I don't bother with the in block.

What do you think about https://github.com/D-Programming-Language/dmd/pull/3799 ?

Basically, turn obviously invalid failing function calls into compile-time errors.  IMO this pushes in-contracts well out of the useless area. 

Daniel Murphy:

> What do you think about https://github.com/D-Programming-Language/dmd/pull/3799 ?
>
> Basically, turn obviously invalid failing function calls into compile-time errors.  IMO this pushes in-contracts well out of the useless area.

I like compile-time tests, you can see it from several of my last posts, but:
1) It's better to be able to express general tests using CTFE, instead of covering a limited but growing list of cases. The general solution needs only half page of text to be explained in a next version of the TDPL, while your proposal will need a growing list of cases;
2) For reasons Walter has explained elsewhere, those tests need to be explicit, even syntactically-wise (and Walter has a strong opinion on this, so it's unlikely you will change his mind. And I agree with him on this).

So far I've seen only one proposal to do this (the Enum Preconditions), and it too has some limits (caused by compilation units, that can be removed turning the Enum Preconditions into things handled like templates).

Bye,
bearophile

On Saturday, 2 August 2014 at 06:44:48 UTC, Walter Bright wrote:
> On 8/1/2014 11:08 PM, Timon Gehr wrote:
>> You evaded the question.
>
> Those have been posted here before, and I responded in detail to them, more than once.
>
> I have nothing new to say about it.

Honestly, how can you be so comfortable with adding a feature
that can be used to so easily cause undefined behavior????

On Friday, 1 August 2014 at 21:50:59 UTC, Jonathan M Davis wrote:
> On Friday, 1 August 2014 at 20:30:19 UTC, Daniel Gibson wrote:
>> Am 01.08.2014 22:16, schrieb eles:
>>> On Friday, 1 August 2014 at 17:43:27 UTC, Timon Gehr wrote:
>>>> On 08/01/2014 07:19 PM, Sebastiaan Koppe wrote:
>>>
>>>> The debug and the release build may be subjected to different input
>>>> and hence traverse different traces of abstract states. It is not
>>>> valid to say that an assertion will never fail just because it hasn't
>>>> failed yet.
>>>
>>> Yes, but is the same for the C apps. There, you have no assertion in the
>>> release build, the release build is optimized (I imagine very few would
>>> use -O0 on it...), then the sefault happens.
>>>
>>
>> But there checks are not optimized away because of assert.
>> assert(x != NULL);
>> if(x != NULL) { ... }
>> in C the if check won't be optimized away in NDEBUG builds, in equivalent D code it would, because the assert would make the compiler assume that x will never be NULL at that point.
>
> And why is that a problem? By definition, if an assertion fails, your code is in an invalid state,

Only in an ideal world. In practice, the condition in the assertion could itself be incorrect. It could be a leftover after a refactoring, for instance.

> and by compiling out assertions, you're basically assuming that they all pass, so you're code's already screwed if the assertion would have failed had it been compiled in. I don't see how having the compiler then use that assertion for optimizations really costs you anything. Worst case, it just makes already invalid code more invalid. You're screwed regardless if the assertion would have failed. And if it would have succeeded, then you just got an efficiency boost thanks to the assertion.
>
> Thinking about it, I'm actually wondering if I should use assertions _more_ so that the compiler might be able to do better optimizations in -release. The extra cost in non-release builds could be worth that extra boost in -release, and as far as correctness goes, it never hurts to have more assertions.
>
> - Jonathan M Davis

On Saturday, 2 August 2014 at 06:01:30 UTC, Walter Bright wrote:
> As to the substance of your question, I can't do it proper justice in a few lines. It's an important issue, and it is worthwhile to thoroughly understand it, especially for the kind of programming you do and the leading role you have in it.
>
> For that I recommend "Object Oriented Software Construction" by Meyers.
>
> http://www.amazon.com/Object-Oriented-Software-Construction-Book-CD-ROM/dp/0136291554/
>
> Don't let the OOP title throw you off. It is a very thorough treatment of contract programming, and the rules and their rationales, but in a readable manner. You won't be sorry you read it. It's only $34 used, a bargain.

Thanks, will read!

"bearophile"  wrote in message news:hnbybyssdlwaomescwvg@forum.dlang.org...

> I like compile-time tests, you can see it from several of my last posts, but:
> 1) It's better to be able to express general tests using CTFE, instead of covering a limited but growing list of cases. The general solution needs only half page of text to be explained in a next version of the TDPL, while your proposal will need a growing list of cases;

This doesn't need a lot of text to explain either: "when possible, the compiler will check preconditions at compile time"

> 2) For reasons Walter has explained elsewhere, those tests need to be explicit, even syntactically-wise (and Walter has a strong opinion on this, so it's unlikely you will change his mind. And I agree with him on this).

I'm really only interested in Walter's opinion when it's coming from Walter. I've responded to Walter's objections and we'll see where that goes.

> So far I've seen only one proposal to do this (the Enum Preconditions), and it too has some limits (caused by compilation units, that can be removed turning the Enum Preconditions into things handled like templates).

I feel like you're confusing this pull request with another enhancement. The discussion should be about whether this exact feature is worthwhile, not if some other feature would solve some other problems.  Do you really think the compiler opportunistically checking preconditions would be a bad thing for D?