On 07/30/2014 07:00 PM, Timon Gehr wrote:
> ...
>
> Isn't this also true for assert statements?

s/statement/expression

"Timon Gehr"  wrote in message news:lrb7qp$3q5$1@digitalmars.com...

> > Yes, this is a much more useful discussion to have than what other
> > people have definined assert to do.
>
> My impression has been:
> This is the discussion Ola wanted to have in the first place.

Yes, I'm sure it was.

> He defined all the terminology he was using, and the distinction was relevant, because it actually captured the 'consequences wrt safety and correctness'.

He provided a different definition of assert.  This certainly helped to show where he was arguing from, but...

> Then his terminology was picked up as a convenient vector for 'attack' and his point was ignored.

... the fact that D's assert does not match another definition of assert, despite using the same name, is not an argument against the definition of D's assert.

The fact that it's unsafe is not contested.  The point is the optimization is reasonable within D's rules wrt assert and -release. 

On 07/30/2014 06:55 PM, Daniel Murphy wrote:
> "Timon Gehr"  wrote in message news:lrb6lf$2tf$1@digitalmars.com...
>
>> I mean, we have at least:
>> <list>
>
> You forgot 'float', which has nothing to do with levitation.
> ...

:D

> This is all true, yet we have to pick names for things.  We could call
> D's purity 'flarwurghle', but is that really better?  D's purity is much
> more closely related to other concepts of purity than it is to
> flarwurghling.
> ...

'flarwurghle' indeed seems a little bit off too.

> And don't forget int, which is not actually an integer.
> ...

I didn't, I though that one was too debatable to bring up because it already has become to be standard in some notable existing programming languages. :)

>> To me, the apt response to a relative newcomer who gets confused by
>> one of those or something like them, especially when used without
>> quotation marks, is not at all similar to "You're misunderstanding and
>> misusing this feature, stop making noise."
>
> No, but that is the similar to the correct response when somebody
> repeatedly argues that you've defined something wrong because somebody
> else defined it differently.
> ...

I must have missed that.

> The discussion on how we _should_ define it is much more interesting,
> and ideally the other one would not come up at all.

Agreed.

On 07/30/2014 05:45 PM, Tofu Ninja wrote:
> On Wednesday, 30 July 2014 at 15:24:57 UTC, Timon Gehr wrote:
>> I see. (Though I secretly still dare to hope for verified OpenGL
>> drivers, or something analogous: it is not completely out of reach
>> theoretically; the machine can be given a quite precise formal
>> specification.)
>
> There is literally no chance in hell for a verified opengl driver. The
> number of permutations on the state alone is astronomical and
> un-testable. Its made even worse by the fact that the hardware changes
> every year or so.
>
> Sources: I am doing an internship at nvidia right now :P

Noted. Up for a challenge? :)

"Timon Gehr"  wrote in message news:lrb86k$428$1@digitalmars.com...

> On 07/30/2014 05:28 PM, H. S. Teoh via Digitalmars-d wrote:
> > Yeah, I think this hair-splitting between assume and assert is ... pure
> > hair-splitting.
>
> Which is pure name-calling.

Only in the sense that saying your argument is wrong is calling you a wrong-argument-maker. 

"Timon Gehr"  wrote in message news:lrb8bp$428$2@digitalmars.com... 

> > No, version(assert) is just about doing introspection on the compiler's
> > configuration.  In release mode that code doesn't even get semantically
> > analysed.
> 
> Isn't this also true for assert statements?

No.

On 7/30/14, 8:17 AM, Daniel Murphy wrote:
> "Andrei Alexandrescu"  wrote in message
> news:lrb1ru$30ag$1@digitalmars.com...
>
>> It's better when you need an expression. -- Andrei
>
> Nooooo!  That's the kind of thinking that leads to using the comma
> operator!!!!

For that there are lambdas.

Before this becomes a silly debate, I was half-serious in the following sense: I get uncomfortable when people say a statement is equivalent with an expression, because replacement can be tedious. I often use that idiom to replace assert with "always assert" inside expressions.


Andrei

On Wednesday, 30 July 2014 at 17:13:47 UTC, Timon Gehr wrote:
> Noted. Up for a challenge? :)
Challenge?

"Andrei Alexandrescu"  wrote in message news:lrb9jb$57u$1@digitalmars.com...

> Before this becomes a silly debate, I was half-serious in the following sense: I get uncomfortable when people say a statement is equivalent with an expression, because replacement can be tedious. I often use that idiom to replace assert with "always assert" inside expressions.

I guess that's a difference in our programming styles - I never use assert as an expression.  I don't like code that uses && || ?: for control flow.

Maybe it's because I started with basic?  I just looks ugly to me, like you're trying to hide it. 

On 7/30/14, 1:39 PM, Daniel Murphy wrote:
> "Ary Borenszweig"  wrote in message news:lrb6ev$2ln$1@digitalmars.com...
>
>> > Because if assert only means 'check this condition' then the optimizer
>> > can't optimize based on the assumption that it's true.
>>
>> Assert means: check this condition and terminate the program if it
>> doesn't hold.
>>
>> So why can't the compiler optimize based on this?
>
> The compiler can optimize based on this.  But with that definition of
> assert it can't optimize based on the assumption that the condition is
> always true, without checking it first.

So assume stays there in release mode and makes the program crash if it doesnt' hold?