https://www.youtube.com/watch?v=e2F2pqeMLuw&list=PL4EvMyUrlAJmEfs8l6oW2BlnALiDu7kGy

31 minutes in, Walter Bright suggests that a supplementary benefit of using contrats is helping the compiler make optimisations.  He uses the example of being able to do faster 32 bit arithmetic when the variables are longs but per contract within the bounds for 32 bits.

I wondered to what extent D compilers are doing this already (peeking at the contract), and what plans if any there are to incorporate these in generating fast code.


Thanks.


Laeeth

Laeeth Isharc:

> Walter Bright suggests that a supplementary benefit of using contrats is helping the compiler make optimisations.

I think no D compilers do this, currently. And no one knows when such things will be added, if ever.

Bye,
bearophile

On Sun, Nov 09, 2014 at 02:45:29PM +0000, bearophile via Digitalmars-d-learn wrote:
> Laeeth Isharc:
> 
> >Walter Bright suggests that a supplementary benefit of using contrats is helping the compiler make optimisations.
> 
> I think no D compilers do this, currently. And no one knows when such things will be added, if ever.
[...]

Walter *did* mention recently that he was planning to eventually take advantage of information in assert()'s as optimizer hints. Not sure when this will happen, though, but it seems inevitable at some point.


T

-- 
Nothing in the world is more distasteful to a man than to take the path that leads to himself. -- Herman Hesse

H. S. Teoh:

> Walter *did* mention recently that he was planning to eventually take
> advantage of information in assert()'s as optimizer hints. Not sure when
> this will happen, though, but it seems inevitable at some point.

And it caused a storm, because it's an awfully bad idea.

Bye,
bearophile

On Sun, Nov 09, 2014 at 04:12:06PM +0000, bearophile via Digitalmars-d-learn wrote:
> H. S. Teoh:
> 
> >Walter *did* mention recently that he was planning to eventually take advantage of information in assert()'s as optimizer hints. Not sure when this will happen, though, but it seems inevitable at some point.
> 
> And it caused a storm, because it's an awfully bad idea.
[...]

It's only a bad idea because people abuse assert() where it's not
appropriate.


T

-- 
I'm still trying to find a pun for "punishment"...

H. S. Teoh:

> It's only a bad idea because people abuse assert() where it's not appropriate.

It's a bad idea because Walter seems unable to understand the difference between verifying and proving.

Bye,
bearophile

Thanks.  Laeeth.

On Sunday, 9 November 2014 at 16:31:46 UTC, bearophile wrote:
> H. S. Teoh:
>
>> It's only a bad idea because people abuse assert() where it's not appropriate.
>
> It's a bad idea because Walter seems unable to understand the difference between verifying and proving.

I fail to see the difference between assert() and a hypothetical assume().

On Sun, Nov 09, 2014 at 09:57:21PM +0000, eles via Digitalmars-d-learn wrote:
> On Sunday, 9 November 2014 at 16:31:46 UTC, bearophile wrote:
> >H. S. Teoh:
> >
> >>It's only a bad idea because people abuse assert() where it's not
> >>appropriate.
> >
> >It's a bad idea because Walter seems unable to understand the difference between verifying and proving.
> 
> I fail to see the difference between assert() and a hypothetical
> assume().

The original meaning of assert() is what assume() means nowadays,
whereas nowadays what people think of as assert() is actually what
enforce() does in Phobos.


T

-- 
In order to understand recursion you must first understand recursion.

On Sunday, 9 November 2014 at 16:31:46 UTC, bearophile wrote:
> H. S. Teoh:
>
>> It's only a bad idea because people abuse assert() where it's not appropriate.
>
> It's a bad idea because Walter seems unable to understand the difference between verifying and proving.
>
> Bye,
> bearophile

On the other hand, making assert a built-in that provides optimization hints has been proposed for C++17:

http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4154.pdf