I have a dilemma here. I have a non-trivial template function which is inside a template struct, and this template is inferred to be @system. I'm testing using a @safe unittest.

I put @safe on the template to see which calls are actually system, and now it compiles.

This is not a solution, because some template parameters might cause the function to truly be @system, and then it just won't compile at all.

I'm struggling to try and figure out how to properly make this function. Not only am I not sure what to test, but I will have to duplicate the function for both @safe and @system versions, or use a mixin.

But this is going to be really painful. I very much depend on the compiler inferring safety for templates, and it's what we recommend to people who want to build their code for all purposes.

Does anyone have any recommendations of how to approach this? Even if I wanted to report a bug, I have no idea why this is happening in this one spot. Why can't the compiler *try* @safe and if it doesn't work, just decay to @system?

-Steve

On 5/1/20 4:40 PM, Steven Schveighoffer wrote:
> 
> Does anyone have any recommendations of how to approach this? Even if I wanted to report a bug, I have no idea why this is happening in this one spot. Why can't the compiler *try* @safe and if it doesn't work, just decay to @system?

I figured out the issue. It was something very stupid, but probably a bug in the compiler. In my efforts to avoid bounds checking, I did this:

char[4] buf;

auto slice = buf.ptr[idx .. buf.length];

This compiles if it's tagged @safe, but will not infer safety.

But I don't need to do this trick anyway, it's a static array! So I just fixed that part of the code.

But I'd say it's a bug in the compiler, it shouldn't accept that as @safe.

Indeed if I just put that in a function, it fails to compile as @safe. I'll need to dustmite it.

For reference, I used a manual dustmite-like process to narrow down this function to the part that fails.

-Steve

On Friday, 1 May 2020 at 21:04:34 UTC, Steven Schveighoffer wrote:
>
> char[4] buf;
>
> auto slice = buf.ptr[idx .. buf.length];

onlineapp.d(3): Error: buf.ptr cannot be used in @safe code, use &buf[0] instead

On 5/1/20 6:46 PM, welkam wrote:
> On Friday, 1 May 2020 at 21:04:34 UTC, Steven Schveighoffer wrote:
>>
>> char[4] buf;
>>
>> auto slice = buf.ptr[idx .. buf.length];
> 
> onlineapp.d(3): Error: buf.ptr cannot be used in @safe code, use &buf[0] instead
> 

Yes, I know. That doesn't happen in my full use case. Which is why I said I need to dustmite it.

But what I did find is that once I changed that line, then it infers @safe.

Essentially, there's a bug in the compiler that has to do with my whole project.

-Steve