We've just enabled warnings as errors in our build system at work and suddenly:

Warning: explicit element-wise assignment <exprnew> is better than <expr>

where <exprnew> and <expr> are expressions picked from the code. For example, this wasn't accepted:

writeAvail_[0 .. buf.length] = buf;

but this was:

writeAvail_[0 .. buf.length] = buf[];

The type of the involved variables were as trivial as ubyte[] and in ubyte[] respectively.

What's the idea?


Andrei

On Tuesday, 15 April 2014 at 06:31:02 UTC, Andrei Alexandrescu wrote:
> We've just enabled warnings as errors in our build system at work and suddenly:
>
> Warning: explicit element-wise assignment <exprnew> is better than <expr>
>
> where <exprnew> and <expr> are expressions picked from the code. For example, this wasn't accepted:
>
> writeAvail_[0 .. buf.length] = buf;
>
> but this was:
>
> writeAvail_[0 .. buf.length] = buf[];
>
> The type of the involved variables were as trivial as ubyte[] and in ubyte[] respectively.
>
> What's the idea?
>
>
> Andrei

The correct syntax is

writeAvail_[0 .. buf.length] = buf[];

as the other syntax is for assigning a single value to all elements of the destination array. At least that's how I've always seen it.

I'm not sure what that warning is talking about though.

Andrei Alexandrescu:

> We've just enabled warnings as errors in our build system at work and suddenly:

It's much better to enable warnings since day -1, that means the day before you start creating your D project.
That's why I'd like D compilers to have warnings active on default and to have a switch to disable them on request (Walter has not yet answered about this idea).


> What's the idea?

The idea is to tell well apart the assignment of values (like scalars and fixed size arrays) from slice assignments. In general if you have a vector operation, use a []. There are corner cases (with arrays of arrays, fixed sized arrays of dynamic arrays, etc), that if you don't use such strict syntax, lead to undefined (ambiguous, weird) situations. The warning helps avoid that problem, and the warning will be replaced by a deprecation later.

Bye,
bearophile

On Tuesday, 15 April 2014 at 06:31:02 UTC, Andrei Alexandrescu wrote:
> We've just enabled warnings as errors in our build system at work and suddenly:
>
> Warning: explicit element-wise assignment <exprnew> is better than <expr>
>
> where <exprnew> and <expr> are expressions picked from the code. For example, this wasn't accepted:
>
> writeAvail_[0 .. buf.length] = buf;
>
> but this was:
>
> writeAvail_[0 .. buf.length] = buf[];
>
> The type of the involved variables were as trivial as ubyte[] and in ubyte[] respectively.
>
> What's the idea?
>
>
> Andrei

It is mostly a style warning but greatly helps to reduce reading ambiguity:

// "assign rvalue to lvalue element-wise"
// OR
// "assign rvalue to all members of lvalue"
// need to know rvalue type to be sure
lvalue[] = rvalue;

// clear and simple
lvalue[] = rvalue[];

On Tuesday, 15 April 2014 at 06:31:02 UTC, Andrei Alexandrescu wrote:
> We've just enabled warnings as errors in our build system at work and suddenly:
>
> Warning: explicit element-wise assignment <exprnew> is better than <expr>
>
> where <exprnew> and <expr> are expressions picked from the code. For example, this wasn't accepted:
>
> writeAvail_[0 .. buf.length] = buf;
>
> but this was:
>
> writeAvail_[0 .. buf.length] = buf[];
>
> The type of the involved variables were as trivial as ubyte[] and in ubyte[] respectively.
>
> What's the idea?
>
>
> Andrei

Funny, I can reproduce up to 2.063.2, but not after that.

On Tuesday, 15 April 2014 at 10:38:06 UTC, Dicebot wrote:
> On Tuesday, 15 April 2014 at 06:31:02 UTC, Andrei Alexandrescu wrote:
>> We've just enabled warnings as errors in our build system at work and suddenly:
>>
>> Warning: explicit element-wise assignment <exprnew> is better than <expr>
>>
>> where <exprnew> and <expr> are expressions picked from the code. For example, this wasn't accepted:
>>
>> writeAvail_[0 .. buf.length] = buf;
>>
>> but this was:
>>
>> writeAvail_[0 .. buf.length] = buf[];
>>
>> The type of the involved variables were as trivial as ubyte[] and in ubyte[] respectively.
>>
>> What's the idea?
>>
>>
>> Andrei
>
> It is mostly a style warning but greatly helps to reduce reading ambiguity:
>
> // "assign rvalue to lvalue element-wise"
> // OR
> // "assign rvalue to all members of lvalue"
> // need to know rvalue type to be sure
> lvalue[] = rvalue;
>
> // clear and simple
> lvalue[] = rvalue[];

Too bad the warning doesn't work both ways, when using a
"gratuitous" []:

void main()
{
     int[][] a = [[], [], []];
     int[] b = [1, 2];

     //"assign rvalue to lvalue element-by-element" ?
     a[] = b[];
}

On Tuesday, 15 April 2014 at 11:23:30 UTC, monarch_dodra wrote:
> On Tuesday, 15 April 2014 at 06:31:02 UTC, Andrei Alexandrescu wrote:
>> We've just enabled warnings as errors in our build system at work and suddenly:
>>
>> Warning: explicit element-wise assignment <exprnew> is better than <expr>
>>
>> where <exprnew> and <expr> are expressions picked from the code. For example, this wasn't accepted:
>>
>> writeAvail_[0 .. buf.length] = buf;
>>
>> but this was:
>>
>> writeAvail_[0 .. buf.length] = buf[];
>>
>> The type of the involved variables were as trivial as ubyte[] and in ubyte[] respectively.
>>
>> What's the idea?
>>
>>
>> Andrei
>
> Funny, I can reproduce up to 2.063.2, but not after that.

I think it was removed because detection implementation was not mature enough and resulted in confusing behavior for corner cases. You have already already spotted one ;)

Dicebot:

>> Funny, I can reproduce up to 2.063.2, but not after that.
>
> I think it was removed because detection implementation was not mature enough and resulted in confusing behavior for corner cases. You have already already spotted one ;)

So much work to put that warning in... -.-

Bye,
bearophile

On Tuesday, 15 April 2014 at 11:27:41 UTC, Dicebot wrote:
> On Tuesday, 15 April 2014 at 11:23:30 UTC, monarch_dodra wrote:
>> Funny, I can reproduce up to 2.063.2, but not after that.
>
> I think it was removed because detection implementation was not mature enough and resulted in confusing behavior for corner cases. You have already already spotted one ;)

Well, I merely found something that is ambiguous to begin with, but didn't trigger a warning. It's not an actual false positive.

Am 15.04.2014 11:18, schrieb bearophile:
> Andrei Alexandrescu:
>
>> We've just enabled warnings as errors in our build system at work and
>> suddenly:
>
> It's much better to enable warnings since day -1, that means the day
> before you start creating your D project.
> That's why I'd like D compilers to have warnings active on default and
> to have a switch to disable them on request (Walter has not yet answered
> about this idea).
>
>
>> What's the idea?
>
> The idea is to tell well apart the assignment of values (like scalars
> and fixed size arrays) from slice assignments. In general if you have a
> vector operation, use a []. There are corner cases (with arrays of
> arrays, fixed sized arrays of dynamic arrays, etc), that if you don't
> use such strict syntax, lead to undefined (ambiguous, weird) situations.
> The warning helps avoid that problem, and the warning will be replaced
> by a deprecation later.
>
> Bye,
> bearophile

It was a error once, but many situations were not detected correctly. So I hope before it becomes deprecated, it should first be properly working.

One example for a situation that did not work correctly:

struct MyArray
{
  int[] opSlice() { ... }
}

void someFunc()
{
  MyArray a;
  int[] b;
  b[] = a[]; // <- problem here. compiler wants you to write b[] = a[][]
}