[billforsternz]

How long did you think about this before making this declaration? How long did Walter Bright think about this before making his decision when designing his language? Not saying you're wrong, just something to think about perhaps.

[WalterBright]

Thank you. I've made many counter-intuitive decisions based on long experience. Sometimes I just have to say "trust me".

Like not allowing macros in D, or version algebra.

[electroly]

C# requires explicit assignment. If an appeal to authority sways you (it shouldn't), you can substitute Anders Hejlsberg instead of this random OP. How long do you suppose Anders Hejlsberg thought about this?

But I contend it's more useful (and interesting) to think about the idea with your own mind instead of tallying up the perceived authority of its supporters and relying on trust. It was also somewhat rude to suggest that the OP had not given their idea much thought. This is a forum for discussion, isn't it?

[WalterBright]

Unfortunately, what happens with explicit assignment is programmers often enough will:

1. just insert '= 0;' to get it to compile

2. insert '= 0;' and then be puzzled by an initialization further along in the code

3. see the '= 0;' and wonder why the programmer did that as 0 was not a valid value for it

A goal of D is to be able to make code more understandable. Forcing a vacuous initialization on the programmer is not conducive to that.

[electroly]

I think you are misunderstanding what C# does here, and what the original poster was suggesting. Maybe we did a poor job of describing it; I assumed people knew C#. The key words in OP's post were "before first use." It sounds like you interpreted this to mean "every variable declaration must immediately assign a value" but that's not how it works. I'll explain C#'s semantics.

An assignment is required at some point before the first read, not in the declaration. It tracks assignments and usages, and it flags a compiler error if you read a variable before assigning to it for the first time. A variable that hasn't been assigned cannot be read.

It means you can do "int a;" and then later in the function do "a = 5;" and the compiler guarantees that you never read the variable before the assignment in any path through the function. You cannot do "int a;" and then read from it; that's a compile-time error.

It does not mean you have to assign something in the declaration. We never need "vacuous" initializations, and this solution works on all types. Indeed, we avoid vacuous initializations so that the compiler will catch use-before-assign bugs at compile time. The situation you described doesn't happen in C#. Our C# variables become readable on their first assignment, not their declaration; the declaration merely sets the scope. There's no need for a state where it's initialized to an invalid value before receiving the first intended assignment, because in C# the variable is completely inaccessible during that time.

[WalterBright]

Ok, I understand that. Thank you for the explanation.

An analogous thing happens in D:

    int x;
    x = 5;

The compiler front end generates two assignments. But then, when it goes through the backend, the first assignment is deleted by what is known as the "dead assignment optimization".

[billforsternz]

I wasn't really appealing to authority. I was just suspecting a familiar pattern that I always find a little distasteful. Person A describes a brilliant idea they're obviously proud of. Person B casually dismisses it and just claims without evidence that the obvious way of doing it is better. I find that pattern to be not only rude, but to suck some of the joy out of life. The fact that person A on this occasion is widely acknowledged as a brilliant practitioner I thought added weight to me pushing back. But I'd be inclined to feel the same way if person A was an enthusiastic wide eyed student (say) with a fresh perspective.

[electroly]

I can't imagine a situation where that sort of response isn't rude. It's polite to assume people have thought about their opinions, and to address the points rather than the person. If they didn't think it through, then you can counter their points.

In any event, I don't think Walter needed any help here. He is an HN veteran and always willing to discuss the points. Every programming language designer loves an opportunity to discuss their language with interested people! There's almost never a truly right answer in language design, just various tradeoffs.

[billforsternz]

We're both seeing rudeness. We both dislike rudeness. I think it's rude to rain on someone's parade. You think it's rude to assume someone hadn't thought through their comment (I basically agree) and to address the person rather than the points (I also basically agree).

You might note my original comment included softening elements ("perhaps", "not saying you're wrong"). In general if you look at all my comments you'll see I'm not a rude person, I'm pretty agreeable in general.

I was (trying to) make a meta point rather than a point about the specific technical issue. I agree (again!) that the last word has not been said on this issue or on any other issue where tradeoffs need to be weighed.

I read Walter's comment and thought "Wow, that's a surprising, clever and innovative idea, I'm impressed". And I just didn't enjoy someone bluntly saying, in effect. "No you're wrong, you shouldn't do it like that". It's as simple as that really. I know blunt exchanges of views are normal for programmers and engineers, I don't have to like it every time.

Finally, I know Walter Bright is no shrinking violet and he definitely doesn't need me to defend him!