On 3/2/18 10:26 AM, Timon Gehr wrote:
> On 02.03.2018 16:05, Steven Schveighoffer wrote:
>> On 3/2/18 10:00 AM, Timon Gehr wrote:
>>> On 02.03.2018 15:39, Steven Schveighoffer wrote:
>>>>
>>>>
>>>>> In this interpetation, -noboundscheck switches DMD to a different dialect of D. In that dialect, out-of-bounds accesses (and overlapping copies, apparently) always have UB, in both @system and @safe code. That defeats the purpose of @safe. Which is why I don't really care for that dialect.
>>>>
>>>> I agree, I think we should remove the option to disable bounds checks on @safe code, in any way. It's too dangerous. If you want performance that comes without bounds checks, use a trusted escape, or write system code.
>>>
>>> I.e., the -release flag should not remove assertions in @safe code, or at the very least it should not turn them into sources of UB.
>>
>> -release flag already operates this way.
> 
> That's not what the spec says:
> 
> https://dlang.org/dmd-linux.html#switch-release
> 
> "Compile release version, which means not emitting run-time checks for contracts and asserts. Array bounds checking is not done for system and trusted functions, and assertion failures are undefined behaviour."

I misunderstood, yes, assertions are turned off in @safe code, but not array bounds checking (which is what I thought you meant).

Yes, I think assertions should be kept in @safe code. It's weird to have array bounds checks kept, but not assertions (which is how you would do equivalent bounds checks in a custom type).

> Note that this is the only way to stop checking assertions. There is no option to just ignore them.

I'm not sure what the purpose of just ignoring assertions and not contracts (which are made up of assertions anyway).

The boundscheck switch can control the bounds checking independently.

> 
>> It's the -noboundscheck or -boundscheck=off that causes problems.
>>
> 
> At least the specification advises to use caution:
> 
> "off: Bounds checks are disabled completely (even in @safe code). This option should be used with caution and as a last resort to improve performance. Confirm turning off @safe bounds checks is worthwhile by benchmarking."

I suppose the one reason to use -boundscheck=off is to check if it does save any performance, and then go in and manually use trusted escapes for those where it counts.

I'd rather have it named, however, -boundscheck=unsafe.

-Steve

On Friday, March 02, 2018 11:25:00 Steven Schveighoffer via Digitalmars-d wrote:
> Yes, I think assertions should be kept in @safe code. It's weird to have array bounds checks kept, but not assertions (which is how you would do equivalent bounds checks in a custom type).

Then just don't compile with -release. I'd be a _lot_ less likely to use assertions if I knew that the compiler was going to leave them in in release mode. Assertions help find bugs, but they aren't doing anything to make the code any more @safe unless some aspect of the compiler assuming that the assertion is true when it's compiled out allows for the compiler to then function in a manner that isn't @safe, which I doubt, but if it does, then that needs to be fixed, not leaving in a bunch of extra checks intended for catching bugs in development.

- Jonathan M Davis

On 3/2/18 1:21 PM, Jonathan M Davis wrote:
> On Friday, March 02, 2018 11:25:00 Steven Schveighoffer via Digitalmars-d
> wrote:
>> Yes, I think assertions should be kept in @safe code. It's weird to have
>> array bounds checks kept, but not assertions (which is how you would do
>> equivalent bounds checks in a custom type).
> 
> Then just don't compile with -release. I'd be a _lot_ less likely to use
> assertions if I knew that the compiler was going to leave them in in release
> mode. Assertions help find bugs, but they aren't doing anything to make the
> code any more @safe unless some aspect of the compiler assuming that the
> assertion is true when it's compiled out allows for the compiler to then
> function in a manner that isn't @safe, which I doubt, but if it does, then
> that needs to be fixed, not leaving in a bunch of extra checks intended for
> catching bugs in development.

As ag says, @safe code is supposed to be free of undefined behavior. If -release means it has undefined behavior, that is a problem. I'd much rather have assertions in release mode than undefined behavior in release mode.

The other option is to make sure the compiler cannot make any assumptions about the asserts when they are compiled out in @safe code.

-Steve