On 25.02.2017 15:38, Chris Wright wrote:
> On Sat, 25 Feb 2017 13:23:03 +0100, Timon Gehr wrote:
>> If 'disable' (as can be reasonably expected) means the compiler will
>> behave as if they were never present, then it does not.
>
> https://dlang.org/dmd-linux.html#switch-release
>

This literally says "[...] assertion failures are undefined behaviour".

https://en.wikipedia.org/wiki/Confirmation_bias

> Plus I actually tested it.
> ...

Why would that matter?

>> Ketmar described the removal of safety measures. With -release,
>> assertions pose an additional safety risk.
>
> Assertions not executing is not undefined behavior.
>

I didn't say it was.


I know my claim seems insane, but it is actually true.

http://forum.dlang.org/post/lr4kek$2rd$1@digitalmars.com

On Saturday, 25 February 2017 at 21:12:13 UTC, Timon Gehr wrote:

>
> I know my claim seems insane, but it is actually true.
>
> http://forum.dlang.org/post/lr4kek$2rd$1@digitalmars.com

The optimizer can currently not take advantage of it.
and I don't see how that would change in the near future.

On Sat, 25 Feb 2017 22:12:13 +0100, Timon Gehr wrote:

> On 25.02.2017 15:38, Chris Wright wrote:
>> On Sat, 25 Feb 2017 13:23:03 +0100, Timon Gehr wrote:
>>> If 'disable' (as can be reasonably expected) means the compiler will behave as if they were never present, then it does not.
>>
>> https://dlang.org/dmd-linux.html#switch-release
>>
>>
> This literally says "[...] assertion failures are undefined behaviour".

...

It says it doesn't emit code for assertions.

Then it says assertion failures are undefined behavior.

How does that even work?

> https://en.wikipedia.org/wiki/Confirmation_bias

Fuck you.

On Sat, 25 Feb 2017 21:49:43 +0000, Chris Wright wrote:

> On Sat, 25 Feb 2017 22:12:13 +0100, Timon Gehr wrote:
> 
>> On 25.02.2017 15:38, Chris Wright wrote:
>>> On Sat, 25 Feb 2017 13:23:03 +0100, Timon Gehr wrote:
>>>> If 'disable' (as can be reasonably expected) means the compiler will behave as if they were never present, then it does not.
>>>
>>> https://dlang.org/dmd-linux.html#switch-release
>>>
>>>
>> This literally says "[...] assertion failures are undefined behaviour".
> 
> ...
> 
> It says it doesn't emit code for assertions.
> 
> Then it says assertion failures are undefined behavior.
> 
> How does that even work?

As far as I can tell, it's worded poorly enough to be incorrect.

The undefined behavior is what happens after the would-be assertion failure occurs. The compiler is free to emit code as if the assertion passed, or if there is no way for the assertion to pass, it is free to do anything it wants.

However, the assertion isn't emitted, so there is no assertion failure. That part is defined behavior; it was defined in the preceding sentence.

On Saturday, 25 February 2017 at 21:49:43 UTC, Chris Wright wrote:
> On Sat, 25 Feb 2017 22:12:13 +0100, Timon Gehr wrote:
>
>> On 25.02.2017 15:38, Chris Wright wrote:
>>> On Sat, 25 Feb 2017 13:23:03 +0100, Timon Gehr wrote:
>>>> If 'disable' (as can be reasonably expected) means the compiler will behave as if they were never present, then it does not.
>>>
>>> https://dlang.org/dmd-linux.html#switch-release
>>>
>>>
>> This literally says "[...] assertion failures are undefined behaviour".
>
> ...
>
> It says it doesn't emit code for assertions.
>
> Then it says assertion failures are undefined behavior.
>
> How does that even work?

LLVM and other optimizers provide functionality for introducing axioms directly. D allows compilers to turn asserts into axioms without proof. If axioms are contradicting each other the whole program becomes potentially undefined (i.e. True and False become arbitrary).

On 02/24/2017 12:47 PM, H. S. Teoh via Digitalmars-d wrote:
>
> The elephant in the room is that the recent craze surrounding the
> "cloud" has conveniently collected large numbers of online services
> under a small number of umbrellas, thereby greatly expanding the impact
> of any bug that occurs in the umbrella.  Instead of a nasty bug that
> impacts merely one or two domains, we now have a nasty bug that
> singlehandedly affects 4 *million* domains.  Way to go, "cloud"
> technology!
>

Indeed. The big original *point* of what became the internet, and why the internet got as successful as it did, was decentralization. The past decade or so of recentralization is a shame, to say the least. But I suppose it was inevitable: Now that corporations are involved, corporate interests are involved, and corporate motivator #1 is "control as much of the territory as you can: size == profit".

On 02/25/2017 04:49 PM, Chris Wright wrote:
>
> It says it doesn't emit code for assertions.
>
> Then it says assertion failures are undefined behavior.
>
> How does that even work?
>

Obviously the would-be failure. No need for the docs to be pedantic about everything. It'd read like the average RFC, for the few people who would bother trying to read it.

On Saturday, 25 February 2017 at 22:37:15 UTC, Chris Wright wrote:
> The undefined behavior is what happens after the would-be assertion failure occurs. The compiler is free to emit code as if the assertion passed, or if there is no way for the assertion to pass, it is free to do anything it wants.

No. That would be implementation defined behaviour. Undefined behaviour means the whole program is illegal, i.e. not covered by the language at all.

On 02/26/2017 12:17 AM, Ola Fosheim Grostad wrote:
> On Saturday, 25 February 2017 at 22:37:15 UTC, Chris Wright wrote:
>> The undefined behavior is what happens after the would-be assertion
>> failure occurs. The compiler is free to emit code as if the assertion
>> passed, or if there is no way for the assertion to pass, it is free to
>> do anything it wants.
>
> No. That would be implementation defined behaviour. Undefined behaviour
> means the whole program is illegal, i.e. not covered by the language at
> all.
>

"Bad things happen" by a different name smells just as foul.

On Sunday, 26 February 2017 at 06:02:59 UTC, Nick Sabalausky (Abscissa) wrote:
> On 02/26/2017 12:17 AM, Ola Fosheim Grostad wrote:
>> On Saturday, 25 February 2017 at 22:37:15 UTC, Chris Wright wrote:
>>> The undefined behavior is what happens after the would-be assertion
>>> failure occurs. The compiler is free to emit code as if the assertion
>>> passed, or if there is no way for the assertion to pass, it is free to
>>> do anything it wants.
>>
>> No. That would be implementation defined behaviour. Undefined behaviour
>> means the whole program is illegal, i.e. not covered by the language at
>> all.
>>
>
> "Bad things happen" by a different name smells just as foul.

Most languages don't accept undefined behaviour, or rather, require it to be detected at either compile time or run time. Are there any languages outside the C family that that allows illegal programs to compile and run undetected under the assumption that such source code will never be compiled (assuming that the programmer will assure that this never happens)?

Implementation defined is different, as the spec can put can put constraints on the implementation, e.g. how a program terminates if you run out of memory might vary, but the spec might specify that an exception should be issued before terminating.