April 15, 2014 What's the deal with "Warning: explicit element-wise assignment..." | ||||
---|---|---|---|---|
| ||||
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 |
April 15, 2014 Re: What's the deal with "Warning: explicit element-wise assignment..." | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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.
|
April 15, 2014 Re: What's the deal with "Warning: explicit element-wise assignment..." | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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 |
April 15, 2014 Re: What's the deal with "Warning: explicit element-wise assignment..." | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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[];
|
April 15, 2014 Re: What's the deal with "Warning: explicit element-wise assignment..." | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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.
|
April 15, 2014 Re: What's the deal with "Warning: explicit element-wise assignment..." | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dicebot | 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[];
}
|
April 15, 2014 Re: What's the deal with "Warning: explicit element-wise assignment..." | ||||
---|---|---|---|---|
| ||||
Posted in reply to monarch_dodra | 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 ;)
|
April 15, 2014 Re: What's the deal with "Warning: explicit element-wise assignment..." | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dicebot | 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
|
April 15, 2014 Re: What's the deal with "Warning: explicit element-wise assignment..." | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dicebot | 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.
|
April 15, 2014 Re: What's the deal with "Warning: explicit element-wise assignment..." | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | 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[][]
}
|
Copyright © 1999-2021 by the D Language Foundation