December 09, 2011
On Thu, 08 Dec 2011 12:18:56 -0500, Joshua Reusch <yoschi@arkandos.de> wrote:>
>> Ahem. So are you suggesting that (a,b) means a tuple everywhere but in a
>> for loop, where it is used to separate two statements?
>
> If we use the comma operator only for tuples, there needn't to be a
> special case for loops:
>
> for(x, y = 0 , 100; x < y ; x, y += 1,-1) { ... }
>
Clever! However,
1) Showing that the trivial example can be expressed with tuples is a good first step. The next step is to go after some of the advanced comma usages. i.e. What's the limitations of this approach? When does it break down?
2) As per the current tuple proposals, the above is a horrendous performance sink. Granted, more tuple awareness in the compiler might fix the problem, but that awareness is more than what's in the current tuple proposals.

December 09, 2011
On Thu, 08 Dec 2011 13:17:44 -0500, so <so@so.so> wrote:

> On Thu, 08 Dec 2011 19:25:10 +0200, Dejan Lekic <dejan.lekic@gmail.com>
> wrote:
>
>>>
>>> type a = a + 2; // compiles with no errors, no warnings, no explosions
>>> (that i know of)
>>
>> If "type" has the default initialiser, then what is the problem?
>
> What does it do in both C and D context?
> 1. It does different things.
> 2. C version even worse because of debug/release difference.
> 3. If D still does this, it violates the B-D rule (either does the same
> thing or doesn't compile at all. Actually there are many things violate
> this rule...)
>
> type a; // even this simple code violates B-D rule.
>
> What is the use case?
> . Is there any?
> . If there is not any you think, but still compiler allows it, it
> generates nothing but bugs (from experience :) ).
>
> Question should be, why does it exist at all?

Actually, these statements don't violate the B-D rule. In C/C++ the value of 'a' prior to use is implementation defined (i.e. it is undefined by the spec) and in practice tends to be some random stack value. D just sets that value to a consistent default, which is completely compliant with the C spec.
December 09, 2011
On Fri, 09 Dec 2011 03:19:34 +0200, Robert Jacques <sandford@jhu.edu>
wrote:

> On Thu, 08 Dec 2011 13:17:44 -0500, so <so@so.so> wrote:
>
>> On Thu, 08 Dec 2011 19:25:10 +0200, Dejan Lekic <dejan.lekic@gmail.com>
>> wrote:
>>
>>>>
>>>> type a = a + 2; // compiles with no errors, no warnings, no explosions
>>>> (that i know of)
>>>
>>> If "type" has the default initialiser, then what is the problem?
>>
>> What does it do in both C and D context?
>> 1. It does different things.
>> 2. C version even worse because of debug/release difference.
>> 3. If D still does this, it violates the B-D rule (either does the same
>> thing or doesn't compile at all. Actually there are many things violate
>> this rule...)
>>
>> type a; // even this simple code violates B-D rule.
>>
>> What is the use case?
>> . Is there any?
>> . If there is not any you think, but still compiler allows it, it
>> generates nothing but bugs (from experience :) ).
>>
>> Question should be, why does it exist at all?
>
> Actually, these statements don't violate the B-D rule. In C/C++ the value of 'a' prior to use is implementation defined (i.e. it is undefined by the spec) and in practice tends to be some random stack value. D just sets that value to a consistent default, which is completely compliant with the C spec.

I disagree. As you said while in C/C++ same thing gets assigned random values,
in D it doesn't. As a result, it changes both the coders' expectations and programs
outcome. Even the definitions are different. Undefined there and defined here.
I am not sure how to express this.

As far as i understand you are saying; Because uninitialized variables are undefined in C,
D can act as another C compiler and interpret this rule as it pleases. But in practice no compiler i know does that.
And "assuming the variable initialized to some value" is a bad programming practice, which i should say the most popular among its kind.
So it clashes with another thing about D, pragmatism.
December 09, 2011
On Thu, 08 Dec 2011 21:23:11 -0500, so <so@so.so> wrote:
> On Fri, 09 Dec 2011 03:19:34 +0200, Robert Jacques <sandford@jhu.edu>
> wrote:
>
>> On Thu, 08 Dec 2011 13:17:44 -0500, so <so@so.so> wrote:
>>
>>> On Thu, 08 Dec 2011 19:25:10 +0200, Dejan Lekic <dejan.lekic@gmail.com>
>>> wrote:
>>>
>>>>>
>>>>> type a = a + 2; // compiles with no errors, no warnings, no explosions
>>>>> (that i know of)
>>>>
>>>> If "type" has the default initialiser, then what is the problem?
>>>
>>> What does it do in both C and D context?
>>> 1. It does different things.
>>> 2. C version even worse because of debug/release difference.
>>> 3. If D still does this, it violates the B-D rule (either does the same
>>> thing or doesn't compile at all. Actually there are many things violate
>>> this rule...)
>>>
>>> type a; // even this simple code violates B-D rule.
>>>
>>> What is the use case?
>>> . Is there any?
>>> . If there is not any you think, but still compiler allows it, it
>>> generates nothing but bugs (from experience :) ).
>>>
>>> Question should be, why does it exist at all?
>>
>> Actually, these statements don't violate the B-D rule. In C/C++ the
>> value of 'a' prior to use is implementation defined (i.e. it is
>> undefined by the spec) and in practice tends to be some random stack
>> value. D just sets that value to a consistent default, which is
>> completely compliant with the C spec.
>
> I disagree. As you said while in C/C++ same thing gets assigned random
> values,
> in D it doesn't. As a result, it changes both the coders' expectations and
> programs
> outcome. Even the definitions are different. Undefined there and defined
> here.
> I am not sure how to express this.
>
> As far as i understand you are saying; Because uninitialized variables are
> undefined in C,
> D can act as another C compiler and interpret this rule as it pleases. But
> in practice no compiler i know does that.
In a discussion about language specifications, practical implementation details seem tangential to me. Besides, many C++ compilers do set variables to a default bit pattern in debug mode, in order to better detect and account for uninitialized variables. D's major difference is that it also does this in release mode. Besides, strictly speaking, the B-D rule is about valid, portable C/C++ code, which (arguably) isn't anything that uses uninitialized variables. In other words, the B-D rule isn't about D mimicking the behavior of a particular C/C++ compiler, it's about the C spec.

> And "assuming the variable initialized to some value" is a bad programming
> practice, which i should say the most popular among its kind.
I totally agree, from a normal control flow perspective. But .init has many uses, particularly in error detection and and repeatability of .init greatly eases debugging.

> So it clashes with another thing about D, pragmatism.
I'm not sure what you mean by that.
December 09, 2011
On Fri, 09 Dec 2011 06:26:27 +0200, Robert Jacques <sandford@jhu.edu> wrote:

>> So it clashes with another thing about D, pragmatism.
> I'm not sure what you mean by that.

It was/is one of the defining points of D AFAIK.
More than being theoretical it chose to be pragmatic, to solve the problems we face day to day.
For the case at hand; Say uninitialized variables in C are undefined but all the compilers do
the same thing that makes it in practice defined. So the below line should execute same on all compilers.

	type a;

Same applies to the extensions supported in all major compilers which is absent in language spec.
If compilers don't support, they can't sell.

To the point. If you want to keep B-D rule with the presence of such big design mistakes (C), you are not being pragmatic at all.
December 09, 2011
On Thursday, 8 December 2011 at 17:18:57 UTC, Joshua Reusch wrote:
>
>> Ahem. So are you suggesting that (a,b) means a tuple everywhere but in a
>> for loop, where it is used to separate two statements?
>
> If we use the comma operator only for tuples, there needn't to be a special case for loops:
>
> for(x, y = 0 , 100; x < y ; x, y += 1,-1) { ... }

for(int x, y = 0 , 100; x < y ; x, y += 1,-1) { ... }

?
December 09, 2011
On 08.12.2011 20:22, Timon Gehr wrote:
> On 12/08/2011 05:02 PM, Regan Heath wrote:
>> On Thu, 08 Dec 2011 12:17:20 -0000, so <so@so.so> wrote:
>>
>>> On Thu, 08 Dec 2011 11:17:48 +0200, Dejan Lekic
>>> <dejan.lekic@gmail.com> wrote:
>>>
>>>>
>>>>>
>>>>> Why is this operator still kept around?
>>>>
>>>> No offense, but I find it strange/funny that you even ask why! :)
>>>>
>>>> Have you never used comma in for loops???
>>>>
>>>
>>> Not sure if it is that relevant for D, but good point.
>>>
>>> for(auto i=beg(), e=end(); i!=e; ++i)
>>> for(auto i, j, k;; ++i, ++k)
>>> ...
>>
>> It's kinda amusing that this thread appeared just as we had a case of
>> this here at work. The developer accidentally coded something like...
>>
>> if (function(..), FALSE)
>> {
>> }
>>
>> Accidentally adding the ", FALSE" /after/ the ) instead of as a new
>> parameter to the function.
>>
>> (note; This was in C++ with default parameter values so the function can
>> in fact take 1-4 args).
>>
>> When I pointed this out, he said "how does that even compile" and was
>> completely unaware of the existence of the comma operator, nor (once I
>> explained it) did he realise it was in any way related to the comma used
>> in for loops. People simply don't think of them as being the same thing
>> at all. Instead, people learn the comma syntax as a special
>> characteristic of the for loop, and use it nowhere else.
>>
>> I think the comma operator is of little benefit (except where used in a
>> for loop) and it is a source of bugs and we'd be better off without it.
>> Even if it means porting C/C++ requires modification, or existing D (I
>> doubt very much of it) breaks.
>>
>
> Phobos would break, for example. And some of my code too.

Are there any cases where you're using comma outside of for loops?
I wonder how much would break if were made illegal everywhere else.
December 09, 2011
On Friday, December 09, 2011 10:19:18 Don wrote:
> Are there any cases where you're using comma outside of for loops? I wonder how much would break if were made illegal everywhere else.

I'm sure that it would break code, but most people consider it bad practice to use the comma operator for much outside of for loops. Occasionally, it's useful to use one in an expression, but on the whole, it's just confusing and error-prone. And while it might break code to make the comma operator illegal outside of for loops, I would expect that fixing the broken code would generally be rather trivial. The resulting code may not be as compact, but it wouldn't be hard to write. And unless you're dealing with a programmer who uses it uncommonly often, not much code is going to break.

- Jonathan M Davis
December 09, 2011
On 12/09/2011 10:19 AM, Don wrote:
> On 08.12.2011 20:22, Timon Gehr wrote:
>> On 12/08/2011 05:02 PM, Regan Heath wrote:
>>> On Thu, 08 Dec 2011 12:17:20 -0000, so <so@so.so> wrote:
>>>
>>>> On Thu, 08 Dec 2011 11:17:48 +0200, Dejan Lekic
>>>> <dejan.lekic@gmail.com> wrote:
>>>>
>>>>>
>>>>>>
>>>>>> Why is this operator still kept around?
>>>>>
>>>>> No offense, but I find it strange/funny that you even ask why! :)
>>>>>
>>>>> Have you never used comma in for loops???
>>>>>
>>>>
>>>> Not sure if it is that relevant for D, but good point.
>>>>
>>>> for(auto i=beg(), e=end(); i!=e; ++i)
>>>> for(auto i, j, k;; ++i, ++k)
>>>> ...
>>>
>>> It's kinda amusing that this thread appeared just as we had a case of
>>> this here at work. The developer accidentally coded something like...
>>>
>>> if (function(..), FALSE)
>>> {
>>> }
>>>
>>> Accidentally adding the ", FALSE" /after/ the ) instead of as a new
>>> parameter to the function.
>>>
>>> (note; This was in C++ with default parameter values so the function can
>>> in fact take 1-4 args).
>>>
>>> When I pointed this out, he said "how does that even compile" and was
>>> completely unaware of the existence of the comma operator, nor (once I
>>> explained it) did he realise it was in any way related to the comma used
>>> in for loops. People simply don't think of them as being the same thing
>>> at all. Instead, people learn the comma syntax as a special
>>> characteristic of the for loop, and use it nowhere else.
>>>
>>> I think the comma operator is of little benefit (except where used in a
>>> for loop) and it is a source of bugs and we'd be better off without it.
>>> Even if it means porting C/C++ requires modification, or existing D (I
>>> doubt very much of it) breaks.
>>>
>>
>> Phobos would break, for example. And some of my code too.
>
> Are there any cases where you're using comma outside of for loops?

Yes, one for every 65 LOC.

> I wonder how much would break if were made illegal everywhere else.

These are the occurences of the comma operator in directory 'std':

return r2.empty ? (r1 = r, true) : false;
return binaryFun!pred(r.front, e) ? (r.popFront(), true) : false;

if (f.flPlus)
    signChar = '+', ++minw;
else if (f.flSpace)
    signChar = ' ', ++minw;

if (std.ascii.toLower(p.front) == 'n' &&
       (p.popFront(), std.ascii.toLower(p.front) == 'f') &&
       (p.popFront(), p.empty))

enforce((p.popFront(), !p.empty && std.ascii.toUpper(p.front) == 'A')
        && (p.popFront(), !p.empty && std.ascii.toUpper(p.front) == 'N'),
       new ConvException("error converting input to floating point"));

if (indexStart != 0)
    formatValue(w, indexStart, f), put(w, '$');

if (c == '\"' || c == '\\')
    put(w, '\\'), put(w, c);
else
    put(w, c);

return (++mi.m_cRefs, cast(HXModule)mi);
return (++mi.m_cRefs, hModule);

return
    c <= 0x7F ? 1
    : c <= 0x7FF ? 2
    : c <= 0xFFFF ? 3
    : c <= 0x10FFFF ? 4
    : (assert(false), 6);





December 09, 2011
On 12/09/2011 10:26 AM, Jonathan M Davis wrote:
> On Friday, December 09, 2011 10:19:18 Don wrote:
>> Are there any cases where you're using comma outside of for loops?
>> I wonder how much would break if were made illegal everywhere else.
>
> I'm sure that it would break code, but most people consider it bad practice to
> use the comma operator for much outside of for loops.

'most people'?

> Occasionally, it's
> useful to use one in an expression, but on the whole, it's just confusing and
> error-prone.

It is confusing to people who don't know the language. It is a simple construct. In my experience, it is certainly not error prone. If you are aware that such an operator exists.

> And while it might break code to make the comma operator illegal
> outside of for loops, I would expect that fixing the broken code would
> generally be rather trivial.

Sure.

> The resulting code may not be as compact, but it
> wouldn't be hard to write.

It would be a PITA in some cases.

> And unless you're dealing with a programmer who
> uses it uncommonly often, not much code is going to break.
>

I _am_ such a programmer.