View mode: basic / threaded / horizontal-split · Log in · Help
April 22, 2012
Re: comma operator causes hard to spot bugs
On 4/21/12, Timon Gehr <timon.gehr@gmx.ch> wrote:
> those could be replaced by ( , )[$-1].

Also known as indexOpRightButtCheek().
April 23, 2012
Re: comma operator causes hard to spot bugs
On 04/23/2012 01:56 AM, deadalnix wrote:
> Le 21/04/2012 18:54, bearophile a écrit :
>> Jonathan M Davis:
>>
>>> There have been discussions about the comma operator before. I don't
>>> expect that it's going anywhere,
>>
>> Maybe there are intermediate solutions between keeping wild commas in D
>> and disallowing them fully. I think most of my bugs caused by commas are
>> similar to the one shown by the OP. This means this is not a common
>> source of bugs:
>>
>> foo(), bar();
>>
>
> This is completely redundant with foo(); bar();

Not completely, you also need  {  }

if(qux()) foo(), bar();

>
> I see no benefit from being able to do this.
April 23, 2012
Re: comma operator causes hard to spot bugs
On Monday, 23 April 2012 at 08:08:52 UTC, Timon Gehr wrote:
> On 04/23/2012 01:56 AM, deadalnix wrote:
>> Le 21/04/2012 18:54, bearophile a écrit :
>>> Jonathan M Davis:
>>>
>>>> There have been discussions about the comma operator before. 
>>>> I don't
>>>> expect that it's going anywhere,
>>>
>>> Maybe there are intermediate solutions between keeping wild 
>>> commas in D
>>> and disallowing them fully. I think most of my bugs caused by 
>>> commas are
>>> similar to the one shown by the OP. This means this is not a 
>>> common
>>> source of bugs:
>>>
>>> foo(), bar();
>>>
>>
>> This is completely redundant with foo(); bar();
>
> Not completely, you also need  {  }
>
> if(qux()) foo(), bar();
>
>>
>> I see no benefit from being able to do this.

I think the most common use-case for the , operator is in the 
"increment part" of for loops... but this could of course be 
special-cased to still be allowed...
April 23, 2012
Re: comma operator causes hard to spot bugs
On 23-04-2012 11:38, CTFE-4-the-win wrote:
> On Monday, 23 April 2012 at 08:08:52 UTC, Timon Gehr wrote:
>> On 04/23/2012 01:56 AM, deadalnix wrote:
>>> Le 21/04/2012 18:54, bearophile a écrit :
>>>> Jonathan M Davis:
>>>>
>>>>> There have been discussions about the comma operator before. I don't
>>>>> expect that it's going anywhere,
>>>>
>>>> Maybe there are intermediate solutions between keeping wild commas in D
>>>> and disallowing them fully. I think most of my bugs caused by commas
>>>> are
>>>> similar to the one shown by the OP. This means this is not a common
>>>> source of bugs:
>>>>
>>>> foo(), bar();
>>>>
>>>
>>> This is completely redundant with foo(); bar();
>>
>> Not completely, you also need { }
>>
>> if(qux()) foo(), bar();
>>
>>>
>>> I see no benefit from being able to do this.
>
> I think the most common use-case for the , operator is in the "increment
> part" of for loops... but this could of course be special-cased to still
> be allowed...
>

Which is what the rest of the world's programming languages (other than 
C and C++) do.

-- 
- Alex
April 24, 2012
Re: comma operator causes hard to spot bugs
> if(r.front == 'a' && (r.popFront(), r.front) == 'b') { ... }
>
> There are a few similar usages in Phobos. If comma was to be used as a  
> tuple constructor instead, those could be replaced by ( , )[$-1].

Tuples with void elements?
And if the first exp had a value one
wouldn't like to pay for the copying.
April 24, 2012
Re: comma operator causes hard to spot bugs
On 04/24/2012 03:21 AM, Martin Nowak wrote:
>> if(r.front == 'a' && (r.popFront(), r.front) == 'b') { ... }
>>
>> There are a few similar usages in Phobos. If comma was to be used as a
>> tuple constructor instead, those could be replaced by ( , )[$-1].
>
> Tuples with void elements?

Yes. They behave similar to void.

> And if the first exp had a value one wouldn't like to pay for the copying.

How would this require copying? D language tuples already work in a way 
that would make (,)[$-1] completely equivalent to what (,) does now.
April 27, 2012
Re: comma operator causes hard to spot bugs
I fully agree! I wonder why the comma operator made it into D at all. 
This would have been exactly the kind of nasty language details that D 
could have cleaned out.



On 21.04.2012 14:23, Benjamin Thaut wrote:
> Hi,
> I just had a bug due to the unitentional usage of the comma operator. So
> I'm wondering if there could something be done so that the compiler
> prevents something like this:
>
> memStart = cast(T*)(m_allocator.AllocateMemory(size * T.sizeof),
> InitializeMemoryWith.NOTHING);
>
> This first excutes AllocateMemory, then throws away the result and then
> casts the enum InitializeMemory.NOTHING value to a pointer, which will
> always result in a null pointer. This took me quite some time to spot.
> What I actually wanted to do:
>
> memStart = cast(T*)(m_allocator.AllocateMemory(size * T.sizeof,
> InitializeMemoryWith.NOTHING));
>
> 1) So is it actually neccessary that enums can be casted directly to
> pointers?
> 2) Is the functionality provided by the comma operator actually worth
> the bugs it causes?
>
> Kind Regards
> Benjamin Thaut
April 27, 2012
Re: comma operator causes hard to spot bugs
Benjamin Thaut wrote:

> I just had a bug due to the unitentional usage of the comma operator.

No language is able to read between the lines. Actually you moved a 
closing parenthesis over a lexical distance of four token.

On this groundadition one can make up similar fruitless remarks.

unintentional usage of exponential:
|  f( 1.0, 1.0e9)
but wanted
|  fe9( 1.0, 1.0)

-manfred
April 27, 2012
Re: comma operator causes hard to spot bugs
On Friday, 27 April 2012 at 21:08:33 UTC, Manfred Nowak wrote:
> unintentional usage of exponential:
> |  f( 1.0, 1.0e9)
> but wanted
> |  fe9( 1.0, 1.0)

I wait for the post where you admit that you made _that_ mistake 
in code as well. Sorry, but I think your own remark is quite a 
bit more fruitless than the one you were commenting on…

David
April 28, 2012
Re: comma operator causes hard to spot bugs
On Saturday, 21 April 2012 at 16:54:49 UTC, bearophile wrote:
> Jonathan M Davis:
>
>> There have been discussions about the comma operator before. I 
>> don't expect that it's going anywhere,
>
> Maybe there are intermediate solutions between keeping wild 
> commas in D and disallowing them fully. I think most of my bugs 
> caused by commas are similar to the one shown by the OP. This 
> means this is not a common source of bugs:
>
> foo(), bar();
>
> While this is sometimes a trap:
>
> auto x = foo(), bar();
>
> So maybe it's enough to disallow using the last expression of a 
> comma sequence as result of the whole expression? I don't know. 
> I almost never use commas for such purposes. What are the use 
> case for those commas?

 Well here's my two cents. Commas should only be used to separate 
parameters, and one exception to this is in for and foreach where 
they have specific purposes. With the way automatic type 
detection I would say instead remove them entirely. For the few 
for cases where you need multiple commands, use a block statement 
instead.

 for(; c < x.length; c++, othercommands)
becomes
 for(; c < x.length; {c++; othercommands;})

Actually seeing that you know the last block is together within 
the {}'s. Could also add that for the init part, but not the 
conditional. Course if it had to return something, then 'return' 
could be applicable. No return, then it's automatically type void.

//TDPL pg 61
int a = 5
int b = 10
int c = (a = b, b = 7, 8);

becomes:

int c = {a = b; b = 7; 8;};
int c = {a = b; b = 7; return 8;};

int[] x;
foreach(i, val; x) //still applicable, but only real case now 
that i can think of.

 Like this it looks less like a function call and a scope 
instead; but still returns something from a scope as it's return 
value. Although then it's almost a lambda function, except 
without calling parameters. Mmm thoughts?
1 2 3
Top | Discussion index | About this forum | D home