Thread overview
Does slicing have an effect?
May 21, 2019
Dennis
May 21, 2019
rikki cattermole
May 27, 2019
XavierAP
May 25, 2019
Max Haughton
May 21, 2019
I was replacing a memcpy with a slice assignment and accidentally used == instead of =.
Usually the compiler protects me from mistakes like that:

```
int[4] a;
a == a;
```
Error: a == a has no effect

However, because I was using slices it didn't:
```
int[4] a;
a[] == a[];
```
No errors

Does slicing have an effect I'm not aware of, or is this a bug?
May 22, 2019
On 22/05/2019 8:31 AM, Dennis wrote:
> I was replacing a memcpy with a slice assignment and accidentally used == instead of =.
> Usually the compiler protects me from mistakes like that:
> 
> ```
> int[4] a;
> a == a;
> ```
> Error: a == a has no effect
> 
> However, because I was using slices it didn't:
> ```
> int[4] a;
> a[] == a[];
> ```
> No errors
> 
> Does slicing have an effect I'm not aware of, or is this a bug?

It could have an effect if a was a struct/class via operator overloads. But in this case it should probably be a bug.
May 25, 2019
On Tuesday, 21 May 2019 at 20:31:58 UTC, Dennis wrote:
> I was replacing a memcpy with a slice assignment and accidentally used == instead of =.
> Usually the compiler protects me from mistakes like that:
>
> ```
> int[4] a;
> a == a;
> ```
> Error: a == a has no effect
>
> However, because I was using slices it didn't:
> ```
> int[4] a;
> a[] == a[];
> ```
> No errors
>
> Does slicing have an effect I'm not aware of, or is this a bug?

It calls druntime( https://d.godbolt.org/z/3gS3-E ), so technically it does have an effect, even if that effect is completely unused and therefore optimized away. Whether this should be considered an effect or not is up to you
May 27, 2019
On Tuesday, 21 May 2019 at 20:44:49 UTC, rikki cattermole wrote:
> On 22/05/2019 8:31 AM, Dennis wrote:
>> 
>> Does slicing have an effect I'm not aware of, or is this a bug?
>
> It could have an effect if a was a struct/class via operator overloads. But in this case it should probably be a bug.

It doesn't look right, even for custom types; because D (and in particular Walter) is against changing the meaning of operators when overloading (e.g. << in C++). At least unofficially, although I may recall it is enforced at a few places elsewhere.

Going back to the original question, it may be a bug (for arrays). And if so and if D wants to enforce consistent operator semantics when possible, it may be considered a bug for any type.