On 7/30/14, 9:20 AM, Walter Bright wrote:
> On 7/30/2014 7:51 AM, Andrei Alexandrescu wrote:
>> Also, it's unclear to me what the optimizer would be supposed to do if an
>> assumption turns out to be false.
>
> The program is no longer valid at that point.

So then:

assert == assume
assert === assume (per proposed notation)
assert is assume
assert <= assume
assume <= assert
assert.opEquals(assume)
assert.opCmp(assume) == 0


Andrei

On 07/30/2014 07:15 PM, Daniel Murphy wrote:
> "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.

Well, no. (Not applicable here, but if it doesn't come with any justification, it might be.)

The second issue is that the statement above tries to look like it is tautological by seeming to express both factual information and an opinion at the same time.

In any case, I wouldn't have objected in this way to a statement like 'I think the distinction between assume and assert is not important for D.', while a statement like
'I think the distinction between assume and assert is not important and I am right about this.', which is what the above statement says, without summoning images of futile attempts to split a hair in half, I am sure, wouldn't even have been considered by the author.

"Ary Borenszweig"  wrote in message news:lrba7m$5o4$1@digitalmars.com... 

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

Yes.  Well, might make it crash.  Might make it just give the wrong result.

On 7/30/14, 9:31 AM, Timon Gehr wrote:
> On 07/30/2014 05:04 PM, Andrei Alexandrescu wrote:
>> On 7/30/14, 4:56 AM, Daniel Murphy wrote:
>>> "Artur Skawina via Digitalmars-d"  wrote in message
>>> news:mailman.217.1406713015.16021.digitalmars-d@puremagic.com...
>>>
>>>> `assert` is for *verifying* assumptions. It must not allow them
>>>> to leak/escape. Otherwise a single not-100%-correct assert could
>>>> defeat critical runtime checks.
>>>
>>> All you're saying is you want them to have different names, not that it
>>> can't work the way Walter and I have described.  If your assertions are
>>> invalid and you're compiling with -release, the compiler is free to
>>> generate invalid code.  -release is dangerous.  -release is telling the
>>> compiler that the code you wrote is correct,  and it can rely on it to
>>> be correct.
>>
>> Exactly! -- Andrei
>
> This just moves the issue around and gives another term a non-obvious
> meaning (the 'release' switch, which is not called e.g.
> 'unsafeAssumeCorrect'.

Well to me "-release" is "I assume my program is correct, generate the fastest code for it".

> Which is still confusing, because it purports to
> keep memory safety intact in @safe code by not disabling array bounds
> checks by default). This is the very topic of this discussion: some
> people get confused when they are assumed to use standard terms with
> non-standard meanings. I was objecting to the apparent attitude that
> this is entirely the fault of the one who gets confused, or that it is
> symptomatic for lack of understanding of concepts.

I'm not sure what would be the standard misused term in this case.

> I mean, we have at least:
>
> some terms with whacky meanings for an outsider:
> 'release' which does not relate to a released code version and which is
> not in contrast to 'debug'.

Yeah, it's a sensible point. I don't like that either, but it's a minor annoyance at most.

> 'const' which does not relate to being a constant.

"Like C++ const, but transitive".

> 'enum' which does not denote enumeration in many contexts where it is used.

Sensible point, but in our use at Facebook I noticed engineers picking it up without a hitch.

> 'in' which does not only check for membership but rather returns a
> pointer to that member.

It's conveniently terse.

> 'lazy', which denotes pass by name instead of pass by need.

It's not pass by name.

> 'pure' which denies access to mutable static variables and IO.

That's the consequence of functional purity as defined by D. I see nothing wrong with it.

> ... (some more easily debatable ones removed)
>
>
> some terms with inconsistent meanings:
> 'alias': alias declarations and alias parameters are notably distinct:
> while I can alias a built-in type to a symbol, I cannot pass it by
> alias. The following fails:
>
> template T(alias a){ enum T=2; }
> pragma(msg, T!string);

Agreed.

> (Before debate ensues: I am completely aware of what each of the above
> actually mean and do.)

I think you got a point there but if you searched any programming language in its pockets you're liable to find a bunch of similar lint. It's the way it goes - there's a need to maximize expressiveness while keeping vocabulary and grammatical constructs low. Few of these items are near the top of my list of issues in D, and I think the same goes for your list.

> 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."

Consider this: after considerable effort you are failing to explain your case for "assume" to the language creators. How do you think you'll fare with newcomers?


Andrei

On Wednesday, 30 July 2014 at 17:57:04 UTC, Andrei Alexandrescu wrote:
> "I assume my program is correct, generate the fastest code for it".

Sounds like description for a command that should trigger "You are fired" e-mail notification.

On 7/30/14, 2:47 PM, Daniel Murphy wrote:
> "Ary Borenszweig"  wrote in message news:lrba7m$5o4$1@digitalmars.com...
>> So assume stays there in release mode and makes the program crash if
>> it doesnt' hold?
>
> Yes.  Well, might make it crash.  Might make it just give the wrong result.

So... it's exactly the same as assert?

"Timon Gehr"  wrote in message news:lrbb2a$6du$1@digitalmars.com...

> The second issue is that the statement above tries to look like it is tautological by seeming to express both factual information and an opinion at the same time.

I prefer to assume statements have no deceptive intent.  Almost everything on here is somebody's opinion, qualified as such or not.

On 7/30/14, 2:59 PM, Ary Borenszweig wrote:
> On 7/30/14, 2:47 PM, Daniel Murphy wrote:
>> "Ary Borenszweig"  wrote in message news:lrba7m$5o4$1@digitalmars.com...
>>> So assume stays there in release mode and makes the program crash if
>>> it doesnt' hold?
>>
>> Yes.  Well, might make it crash.  Might make it just give the wrong
>> result.
>
> So... it's exactly the same as assert?

Sorry, I misunderstood your answer.

If assume stays in release mode then that's the difference. The problem then is that assert doesn't stay in release mode so the compiler can't make any assumption about the code that follows the "assert" because asserts are removed in release mode.

In my opinion, removing asserts in release-mode is the big problem here. How expensive can an assert be? Do you really want to debug that? Wouldn't it be better to get an exception?

If the compiler *never* removes asserts, then assert and assume have the same meaning.

On 07/30/2014 07:46 PM, Andrei Alexandrescu wrote:
> On 7/30/14, 9:20 AM, Walter Bright wrote:
>> On 7/30/2014 7:51 AM, Andrei Alexandrescu wrote:
>>> Also, it's unclear to me what the optimizer would be supposed to do
>>> if an
>>> assumption turns out to be false.
>>
>> The program is no longer valid at that point.
>
> So then:
>
> assert == assume
> assert === assume (per proposed notation)
> assert is assume
> assert <= assume
> assume <= assert
> assert.opEquals(assume)
> assert.opCmp(assume) == 0
>
>
> Andrei
>

You seem to be close to enlightenment:
http://www.madore.org/~david/zen/#conc.dualism

On Wednesday, 30 July 2014 at 17:58:45 UTC, Dicebot wrote:
> On Wednesday, 30 July 2014 at 17:57:04 UTC, Andrei Alexandrescu wrote:
>> "I assume my program is correct, generate the fastest code for it".
>
> Sounds like description for a command that should trigger "You are fired" e-mail notification.

Totally depends on the situation. If you write a SAT solver you can make that assumptions without problems and just verify your results afterwards with a (way simpler) program that was compiled without -release.