On Thursday, 10 April 2014 at 17:25:26 UTC, bearophile wrote:
> Steven Schveighoffer:
>
>> No, the author of the @safe code expects bounds checking, it's part of the requirements.
>
> Take a look ad Ada language. It has bounds checking and its compilers have a switch to disable those checks. If you want the bounds checking don't use the switch that disables the bounds checking. Safety doesn't mean to have no way to work around safety locks. It means have nice handy locks that are active on default. In a system language total safety is an illusion. Better to focus on real world safety and not a illusion of theoretical safety.
>
> Bye,
> bearophile

Yeah, it's like how I have matches in my house. I could use the matches to burn my house down, but I don't think that I will.

That is, unless I can manage to pull off a really good insurance fraud scam.

> A compiler flag is a blunt instrument. It affects all code the compiler touches, which may or may not affect code that you are intending to change.

Yes, such a compiler flag is a blunt and dangerous instrument and everybody should stay away from it. But everybody agrees on those points already. That's _not_ what you need to prove to show that such a flag shouldn't exist. What you need to show is that no-one will ever find them-self in a situation where such a blunt instrument would be useful.

On Thu, 10 Apr 2014 13:25:25 -0400, bearophile <bearophileHUGS@lycos.com> wrote:

> Steven Schveighoffer:
>
>> No, the author of the @safe code expects bounds checking, it's part of the requirements.
>
> Take a look ad Ada language. It has bounds checking and its compilers have a switch to disable those checks. If you want the bounds checking don't use the switch that disables the bounds checking. Safety doesn't mean to have no way to work around safety locks. It means have nice handy locks that are active on default. In a system language total safety is an illusion. Better to focus on real world safety and not a illusion of theoretical safety.

That's why we have @trusted. @safe is a special situation, it's not made for optimization, and should be immune to those attempts in deference to safety.

-Steve

On Thu, 10 Apr 2014 13:35:34 -0400, Tommi <tommitissari@hotmail.com> wrote:

>> A compiler flag is a blunt instrument. It affects all code the compiler touches, which may or may not affect code that you are intending to change.
>
> Yes, such a compiler flag is a blunt and dangerous instrument and everybody should stay away from it. But everybody agrees on those points already. That's _not_ what you need to prove to show that such a flag shouldn't exist. What you need to show is that no-one will ever find them-self in a situation where such a blunt instrument would be useful.

I contend that they won't. @trusted exists and should be used for that purpose.

Note that I could find useful disabling of const checks, or override checks, or dynamic casts. It doesn't mean I should get a compiler switch.

-Steve

On Thursday, 10 April 2014 at 17:37:53 UTC, Steven Schveighoffer wrote:
> On Thu, 10 Apr 2014 13:25:25 -0400, bearophile <bearophileHUGS@lycos.com> wrote:
>
>> Steven Schveighoffer:
>>
>>> No, the author of the @safe code expects bounds checking, it's part of the requirements.
>>
>> Take a look ad Ada language. It has bounds checking and its compilers have a switch to disable those checks. If you want the bounds checking don't use the switch that disables the bounds checking. Safety doesn't mean to have no way to work around safety locks. It means have nice handy locks that are active on default. In a system language total safety is an illusion. Better to focus on real world safety and not a illusion of theoretical safety.
>
> That's why we have @trusted.

No. @trusted is for code that cannot be guaranteed to be memory-safe by the compiler (either at runtime or at compile-time), but the programmer still wants to promise that the code is memory-safe. Array bounds checking doesn't land under that moniker, it can be checked by the compiler.

On Thursday, 10 April 2014 at 17:43:42 UTC, Steven Schveighoffer wrote:
> [..]
> Note that I could find useful disabling of const checks, or override checks, or dynamic casts. It doesn't mean I should get a compiler switch.

There's no point in turning off any safety / correctness checks that can be performed at compile-time. But I could see an argument made for being able to disable any given category of runtime safety checks.

On Thu, 10 Apr 2014 13:45:26 -0400, Tommi <tommitissari@hotmail.com> wrote:

> On Thursday, 10 April 2014 at 17:37:53 UTC, Steven Schveighoffer wrote:
>> On Thu, 10 Apr 2014 13:25:25 -0400, bearophile <bearophileHUGS@lycos.com> wrote:
>>
>>> Take a look ad Ada language. It has bounds checking and its compilers have a switch to disable those checks. If you want the bounds checking don't use the switch that disables the bounds checking. Safety doesn't mean to have no way to work around safety locks. It means have nice handy locks that are active on default. In a system language total safety is an illusion. Better to focus on real world safety and not a illusion of theoretical safety.
>>
>> That's why we have @trusted.
>
> No. @trusted is for code that cannot be guaranteed to be memory-safe by the compiler (either at runtime or at compile-time), but the programmer still wants to promise that the code is memory-safe. Array bounds checking doesn't land under that moniker, it can be checked by the compiler.

@safe code can be marked as @trusted instead, and nothing changes, except @trusted code can have bounds checks removed. How does this not work as a solution?

As Walter often says about logical const, logical @safe is @safe by convention, and it loses all of its teeth.

-Steve

On Thu, 10 Apr 2014 13:52:54 -0400, Tommi <tommitissari@hotmail.com> wrote:

> On Thursday, 10 April 2014 at 17:43:42 UTC, Steven Schveighoffer wrote:
>> [..]
>> Note that I could find useful disabling of const checks, or override checks, or dynamic casts. It doesn't mean I should get a compiler switch.
>
> There's no point in turning off any safety / correctness checks that can be performed at compile-time.

Unless they are warranted. See cast for instance.

> But I could see an argument made for being able to disable any given category of runtime safety checks.

As a compiler switch? I don't think it's worth it. -noboundscheck does what it does for historical reasons, not logical.

-Steve

On Thursday, 10 April 2014 at 17:56:04 UTC, Steven Schveighoffer wrote:
> @safe code can be marked as @trusted instead, and nothing changes, except @trusted code can have bounds checks removed. How does this not work as a solution?

A compiler flag for disabling bounds checking is a blunt instrument. But using search & replace to change each @safe to @trusted is a blunt _and_ inconvenient instrument.

On Thu, 10 Apr 2014 14:08:48 -0400, Tommi <tommitissari@hotmail.com> wrote:

> On Thursday, 10 April 2014 at 17:56:04 UTC, Steven Schveighoffer wrote:
>> @safe code can be marked as @trusted instead, and nothing changes, except @trusted code can have bounds checks removed. How does this not work as a solution?
>
> A compiler flag for disabling bounds checking is a blunt instrument. But using search & replace to change each @safe to @trusted is a blunt _and_ inconvenient instrument.

So don't use it bluntly. For example, disabling bounds checks on the args array in main will not help your performance.

As a general rule, first profile, then optimize.

-Steve