a[0..10][] = a[5..15][];

I.e. - is it well defined to copy between overlapping slices? Does it matter if, in the copy, the source is overlapping the end or the beginning of the destination?

On Thursday, 1 March 2018 at 14:54:41 UTC, Shachar Shemesh wrote:
> I.e. - is it well defined to copy between overlapping slices?

No: https://dlang.org/spec/arrays.html#overlapping-copying

 —David

On 03/01/2018 04:34 PM, David Nadlinger wrote:
> On Thursday, 1 March 2018 at 14:54:41 UTC, Shachar Shemesh wrote:
>> I.e. - is it well defined to copy between overlapping slices?
> 
> No: https://dlang.org/spec/arrays.html#overlapping-copying

Does that mean it has undefined behavior and should not be allowed in @safe code?

On 3/1/18 11:48 AM, ag0aep6g wrote:
> On 03/01/2018 04:34 PM, David Nadlinger wrote:
>> On Thursday, 1 March 2018 at 14:54:41 UTC, Shachar Shemesh wrote:
>>> I.e. - is it well defined to copy between overlapping slices?
>>
>> No: https://dlang.org/spec/arrays.html#overlapping-copying
> 
> Does that mean it has undefined behavior and should not be allowed in @safe code?

No, it means it's a runtime error.

https://run.dlang.io/is/xdiKxx

-Steve

On Thursday, 1 March 2018 at 17:06:48 UTC, Steven Schveighoffer wrote:
> On 3/1/18 11:48 AM, ag0aep6g wrote:
[...]
>> Does that mean it has undefined behavior and should not be allowed in @safe code?
>
> No, it means it's a runtime error.

But then it's well-defined, like going beyond array bounds, no?

On 3/1/18 12:31 PM, ag0aep6g wrote:
> On Thursday, 1 March 2018 at 17:06:48 UTC, Steven Schveighoffer wrote:
>> On 3/1/18 11:48 AM, ag0aep6g wrote:
> [...]
>>> Does that mean it has undefined behavior and should not be allowed in @safe code?
>>
>> No, it means it's a runtime error.
> 
> But then it's well-defined, like going beyond array bounds, no?

Yes it behaves just like array bounds. No it's not well-defined if you disable asserts.

-Steve

On Thursday, 1 March 2018 at 19:05:26 UTC, Steven Schveighoffer wrote:
> Yes it behaves just like array bounds. No it's not well-defined if you disable asserts.

Right. So it's defined to throw an Error in @safe code, and it has undefined behavior in @system code. The spec should say this.

On 3/1/18 3:06 PM, ag0aep6g wrote:
> On Thursday, 1 March 2018 at 19:05:26 UTC, Steven Schveighoffer wrote:
>> Yes it behaves just like array bounds. No it's not well-defined if you disable asserts.
> 
> Right. So it's defined to throw an Error in @safe code, and it has undefined behavior in @system code. The spec should say this.

No.

----
version(dosafe)
{
    void main() @safe
    {
        int[4] arr;
        arr[0 .. 3] = arr[1 .. 4];
    }
}
else
{
    void main()
    {
        int[4] arr;
        arr[0 .. 3] = arr[1 .. 4];
    }
}
---

dmd -version=dosafe -noboundscheck -run testarrayoverlap.d => no error, undefined behavior
dmd -run testarrayoverlap.d => error

@safe has nothing to do with it.

-Steve

On Thursday, 1 March 2018 at 20:14:07 UTC, Steven Schveighoffer wrote:
> dmd -version=dosafe -noboundscheck -run testarrayoverlap.d => no error, undefined behavior
> dmd -run testarrayoverlap.d => error
>
> @safe has nothing to do with it.

@safe has everything to do with. @safe guarantees that there's no undefined behavior. If you can trigger UB in @safe code, that's a bug. The guarantee must hold whether asserts are enabled or not. -noboundscheck does not just disable asserts, it undermines @safe, rendering it meaningless.

For just disabling asserts (without affecting @safe), there's -release. With your same code, `dmd -release` => UB, but `dmd -release -version=dosafe` => Error.

On 3/1/18 3:24 PM, ag0aep6g wrote:
> On Thursday, 1 March 2018 at 20:14:07 UTC, Steven Schveighoffer wrote:
>> dmd -version=dosafe -noboundscheck -run testarrayoverlap.d => no error, undefined behavior
>> dmd -run testarrayoverlap.d => error
>>
>> @safe has nothing to do with it.
> 
> @safe has everything to do with. @safe guarantees that there's no undefined behavior. If you can trigger UB in @safe code, that's a bug. The guarantee must hold whether asserts are enabled or not. -noboundscheck does not just disable asserts, it undermines @safe, rendering it meaningless.

Yeah, it seems like -noboundscheck should never be used.

It's undefined behavior if the check is disabled. How you get the check disabled may be affected by @safe, but whether it's UB or not has nothing to do with @safe. It has to do with "I turned off the checks". Basically, in D, if your program *would have* thrown an Error, but didn't because you turned it off, the compiler is free to assume UB.

> 
> For just disabling asserts (without affecting @safe), there's -release. With your same code, `dmd -release` => UB, but `dmd -release -version=dosafe` => Error.

I was unaware that it would work this way. I thought it would be the same whether you used @safe or not with -release.

-Steve