Comma operator = broken design

[Robert Jacques]

On Thu, 08 Dec 2011 21:23:11 -0500, so <so at so.so> wrote:
> On Fri, 09 Dec 2011 03:19:34 +0200, Robert Jacques <sandford at jhu.edu>
> wrote:
>
>> On Thu, 08 Dec 2011 13:17:44 -0500, so <so at so.so> wrote:
>>
>>> On Thu, 08 Dec 2011 19:25:10 +0200, Dejan Lekic <dejan.lekic at 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.