On Friday, 11 April 2014 at 13:13:22 UTC, Steven Schveighoffer wrote:
> On Fri, 11 Apr 2014 08:35:07 -0400, Daniel Murphy <yebbliesnospam@gmail.com> wrote:
>
>> "Steven Schveighoffer"  wrote in message news:op.xd3vzecweav7ka@stevens-macbook-pro.local...
>>
>>> No, the author of the @safe code expects bounds checking, it's part of the requirements. To compile his code with it off is like having
>>>  -compilergeneratedhash switch that overrides any toHash functions with a compiler generated one. You are changing the agreement between the compiler and the code. When I say @safe, I mean "I absolutely always want bounds checks."
>>
>> If you have code that would ever fail a bounds check, that is a program error, similar to code that may fail an assertion.
>>
>> And like assertions, if you would rather the code was as fast as possible instead of as safe as possible you can use a compiler switch to disable bound checks.
>>
>> The usual switch to do stuff like this is '-release', but because @safe functions should still have the 'no memory corruption' even in release mode, disabling those bounds checks was moved into another compiler switch.
>>
>>> If you want to eliminate bounds checks, use @trusted.
>>
>> No, @trusted means "don't check my code" while @safe + noboundschecks means (mostly) "only check my code at compile-time".
>
> Here is the horror scenario I envision:
>
> 1. Company has 100kLOC project, which is marked as @safe (I can dream, can't I?)
> 2. They find that performance is lacking, maybe compared to a competitor's C++ based code.
> 3. They try compiling with -noboundscheck, get a large performance boost. It really only makes a difference in one function (the inner loop one).
> 4. They pat themselves on the back, and release with the new flag, destroying all bounds checks, even bounds checks in library template code that they didn't write or scrutinize.
> 5. Buffer overflow attacks abound.
> 6. D @safe is labeled a "joke"

More likely:
6. This company's programming department is labeled a "joke".


> There should be a way to say, "I still want all the @safety checks, except for this one critical array access, I have manually guaranteed the bounds". We don't have anything like that.

We have array.ptr[idx]

On Fri, 11 Apr 2014 09:35:12 -0400, Tommi <tommitissari@hotmail.com> wrote:

> On Friday, 11 April 2014 at 13:13:22 UTC, Steven Schveighoffer wrote:
>> Here is the horror scenario I envision:
>>
>> 1. Company has 100kLOC project, which is marked as @safe (I can dream, can't I?)
>> 2. They find that performance is lacking, maybe compared to a competitor's C++ based code.
>> 3. They try compiling with -noboundscheck, get a large performance boost. It really only makes a difference in one function (the inner loop one).
>> 4. They pat themselves on the back, and release with the new flag, destroying all bounds checks, even bounds checks in library template code that they didn't write or scrutinize.
>> 5. Buffer overflow attacks abound.
>> 6. D @safe is labeled a "joke"
>
> More likely:
> 6. This company's programming department is labeled a "joke".

Perhaps, but it doesn't change the idea that @safe code had memory bugs. What we are saying with @safe is that you CAN'T have memory bugs, no matter how incompetent your programmers are.

>> There should be a way to say, "I still want all the @safety checks, except for this one critical array access, I have manually guaranteed the bounds". We don't have anything like that.
>
> We have array.ptr[idx]

Not allowed in @safe code.

-Steve

"Steven Schveighoffer"  wrote in message news:op.xd5lomc1eav7ka@stevens-macbook-pro.local...

> Here is the horror scenario I envision:
>
> 1. Company has 100kLOC project, which is marked as @safe (I can dream, can't I?)
> 2. They find that performance is lacking, maybe compared to a competitor's C++ based code.
> 3. They try compiling with -noboundscheck, get a large performance boost. It really only makes a difference in one function (the inner loop one).
> 4. They pat themselves on the back, and release with the new flag, destroying all bounds checks, even bounds checks in library template code that they didn't write or scrutinize.
> 5. Buffer overflow attacks abound.
> 6. D @safe is labeled a "joke"

Trying to prevent developer stupidity is a lost cause.

Bounds checks are on by default.  They are even on when you ask for 'fast-over-safe' aka -release.  They get turned off when you explicitly ask for it.

> But there is a cost, even to labeling the "one inner" function @trusted. Perhaps that function is extremely long and complex. There should be a way to say, "I still want all the @safety checks, except for this one critical array access, I have manually guaranteed the bounds". We don't have anything like that. All other safety checks are really static, this is the only runtime penalty for safety.

Something like (() @trusted => arr.ptr[index]) should do the trick.

> The blunt flag approach is scary. @trusted is better, in that you can focus on one function at a time. But I think we need something more precise. Perhaps you should be able to have @trusted scopes, or @trusted expressions.

@trusted delegates get you 99.99% of the way there. 

On Friday, 11 April 2014 at 13:44:09 UTC, Steven Schveighoffer wrote:
> On Fri, 11 Apr 2014 09:35:12 -0400, Tommi <tommitissari@hotmail.com> wrote:
>
>> On Friday, 11 April 2014 at 13:13:22 UTC, Steven Schveighoffer wrote:
>>> [..]
>>> 6. D @safe is labeled a "joke"
>>
>> More likely:
>> 6. This company's programming department is labeled a "joke".
>
> Perhaps, but it doesn't change the idea that @safe code had memory bugs. What we are saying with @safe is that you CAN'T have memory bugs, no matter how incompetent your programmers are.

You can't gurantee @safe to be memory-safe in the general case without disallowing calls to @trusted, because those incompenent programmers can write buggy @trusted functions and call them from @safe code.


>>> There should be a way to say, "I still want all the @safety checks, except for this one critical array access, I have manually guaranteed the bounds". We don't have anything like that.
>>
>> We have array.ptr[idx]
>
> Not allowed in @safe code.


@trusted ref T unsafeIndex(T)(T[] array, ulong idx)
{
    return array.ptr[idx];
}

There you go.

On Friday, 11 April 2014 at 14:06:33 UTC, Daniel Murphy wrote:
> Trying to prevent developer stupidity is a lost cause.
>
> Bounds checks are on by default.  They are even on when you ask for 'fast-over-safe' aka -release.  They get turned off when you explicitly ask for it.
>
>> But there is a cost, even to labeling the "one inner" function @trusted. Perhaps that function is extremely long and complex. There should be a way to say, "I still want all the @safety checks, except for this one critical array access, I have manually guaranteed the bounds". We don't have anything like that. All other safety checks are really static, this is the only runtime penalty for safety.
>
> Something like (() @trusted => arr.ptr[index]) should do the trick.
>
>> The blunt flag approach is scary. @trusted is better, in that you can focus on one function at a time. But I think we need something more precise. Perhaps you should be able to have @trusted scopes, or @trusted expressions.
>
> @trusted delegates get you 99.99% of the way there.

Hasn't there been a proposal before to allow @system/@trusted/@safe blocks, allowing it to be a bit more granular than at the function level? Maybe:

@trusted
{
    arr.ptr[index]
}

Could be lowered to (() @trusted => arr.ptr[index]).

On Friday, 11 April 2014 at 15:15:21 UTC, Meta wrote:
> Hasn't there been a proposal before to allow @system/@trusted/@safe blocks, allowing it to be a bit more granular than at the function level? Maybe:
>
> @trusted
> {
>     arr.ptr[index]
> }
>
> Could be lowered to (() @trusted => arr.ptr[index]).

I think it was rejected for the very reason that it gives nothing over writing this:

() @trusted
{
    arr.ptr[index];
}();

It has resulted in some changes by Kenji though that guarantee that immediately-called delegate is always inlined. Hope those were merged.

On Friday, 11 April 2014 at 15:43:16 UTC, Dicebot wrote:
> On Friday, 11 April 2014 at 15:15:21 UTC, Meta wrote:
>> Hasn't there been a proposal before to allow @system/@trusted/@safe blocks, allowing it to be a bit more granular than at the function level? Maybe:
>>
>> @trusted
>> {
>>    arr.ptr[index]
>> }
>>
>> Could be lowered to (() @trusted => arr.ptr[index]).
>
> I think it was rejected for the very reason that it gives nothing over writing this:
>
> () @trusted
> {
>     arr.ptr[index];
> }();
>
> It has resulted in some changes by Kenji though that guarantee that immediately-called delegate is always inlined. Hope those were merged.

Besides the fact that it's incredibly ugly.

On Friday, 11 April 2014 at 15:45:41 UTC, Meta wrote:
> Besides the fact that it's incredibly ugly.

Which is not enough for introduction of any single new feature at current stage.

On Fri, 11 Apr 2014 11:43:15 -0400, Dicebot <public@dicebot.lv> wrote:

> On Friday, 11 April 2014 at 15:15:21 UTC, Meta wrote:
>> Hasn't there been a proposal before to allow @system/@trusted/@safe blocks, allowing it to be a bit more granular than at the function level? Maybe:
>>
>> @trusted
>> {
>>     arr.ptr[index]
>> }
>>
>> Could be lowered to (() @trusted => arr.ptr[index]).
>
> I think it was rejected for the very reason that it gives nothing over writing this:
>
> () @trusted
> {
>      arr.ptr[index];
> }();
>
> It has resulted in some changes by Kenji though that guarantee that immediately-called delegate is always inlined. Hope those were merged.

If this works as seamlessly as a statement, that is a reasonable solution.

Re: ugliness, it's not important. These are not common situations.

-Steve

"Meta"  wrote in message news:brrbqfpkfkevxbseoxiq@forum.dlang.org...

> Hasn't there been a proposal before to allow @system/@trusted/@safe blocks, allowing it to be a bit more granular than at the function level? Maybe:
>
> @trusted
> {
>      arr.ptr[index]
> }
>
> Could be lowered to (() @trusted => arr.ptr[index]).

It's a little prettier, but less powerful and not really something that _should_ be pretty.