On 11/25/17 5:13 PM, Adam D. Ruppe wrote:
> On Saturday, 25 November 2017 at 16:16:52 UTC, A Guy With a Question wrote:
>> If D chooses it's defaults to make errors stick out, why not just error at declaration if they don't explicitly set it to something.
> 
> It technically did:
> 
> https://dlang.org/spec/function.html#local-variables
> 
> "It is an error to use a local variable without first assigning it a value. The implementation may not always be able to detect these cases. Other language compilers sometimes issue a warning for this, but since it is always a bug, it should be an error. "
> 
> 
> But that paragraph was never implemented (it is a bit easier said than done to actually detect given if conditions and stuff too, especially in the early days of D when the compiler didn't even make any effort to track such things, though it does now...). The compiler author took the easy way out of initializing them to invalid values instead.
> 
> While it is more realistic to implement technically now than it was years ago when the current behavior got in, I think we're at the point now that so many people use it as a convenience thing on ints and nulls that there'd be hell to pay if the compiler actually started calling it an error :(
> 

I rely on the default value initialization all the time! I don't know how that would jive with structs, since they are technically local variables, but usually are valid without initialization.

What about AAs? Would you have to do = []?

-Steve

On Saturday, 25 November 2017 at 09:39:15 UTC, Dave Jones wrote:
> I mean at the end of the day, that would turn a run time error into a compile time error which is a good thing isnt it?

Debatable in this case. Consider:

string servicePhoneNumber;

final switch (car.manufacturer) //an enumerated value.
{   case CarMaker.Audi:
        servicePhoneNumber = staff["Dorff Hans"].phone;
        //...
    break;
    case CarMaker.Skoda:
        servicePhoneNumber = staff["Telegin Svetlana"].phone;
        //...
    break;
    //more cases ...
}

Here it is arguably unnecessary typing if you had to manually set servicePhoneNumber to "" or something at start. And in case of structs it tends to be a verbose thing to manually set one to it's init value.

On Monday, 27 November 2017 at 16:04:14 UTC, Dukc wrote:
> Debatable in this case. Consider:
>
> string servicePhoneNumber;
>
> final switch (car.manufacturer) //an enumerated value.

Well, the compiler can see it is initialized before being read again later, so that *should* pass the check (at least conservatively- the spec is flexible enough to let the compiler not catch them all).

On Monday, 27 November 2017 at 14:58:42 UTC, Steven Schveighoffer wrote:
> I rely on the default value initialization all the time! I don't know how that would jive with structs, since they are technically local variables, but usually are valid without initialization.

Yes, indeed, me too. I like it now.

But there might be a compromise that is still workable: let structs and ints (and bytes, short, etc) be exceptions and not issue an error there. But then conservatively check other types. If the compiler sees any read before any write, issue the error. Otherwise, keep the status quo.

That's fit the spec and catch real bugs more often than false positives.

Though, I'm in no ruse to see that implemented either, overall I am meh on it.

> What about AAs? Would you have to do = []?

they could be an exception too, but you could do = null (= [] won't pass the type check lol)

On Saturday, 25 November 2017 at 22:13:43 UTC, Adam D. Ruppe wrote:

> It technically did:
>
> https://dlang.org/spec/function.html#local-variables
>
> "It is an error to use a local variable without first assigning it a value. The implementation may not always be able to detect these cases. Other language compilers sometimes issue a warning for this, but since it is always a bug, it should be an error. "
>
>
> But that paragraph was never implemented (it is a bit easier said than done to actually detect given if conditions and stuff too, especially in the early days of D when the compiler didn't even make any effort to track such things, though it does now...). The compiler author took the easy way out of initializing them to invalid values instead.

WOW!! I am shocked to learn this.  All this time, I though it was a design oversight.  I think I'm going to implement a feature gate to require explicit initialization.  It would be better to be strict up front and relax it as flow control analysis becomes more mature.

Mike

On Monday, 27 November 2017 at 23:05:55 UTC, Michael V. Franklin wrote:

> I think I'm going to implement a feature gate to require explicit initialization.  It would be better to be strict up front and relax it as flow control analysis becomes more mature.

Well, I implemented it (https://github.com/dlang/dmd/pull/7375), but it's off to a pretty rocky start.

Mike

On Tuesday, 28 November 2017 at 20:00:53 UTC, Michael V. Franklin wrote:
> On Monday, 27 November 2017 at 23:05:55 UTC, Michael V. Franklin wrote:
>
>> I think I'm going to implement a feature gate to require explicit initialization.  It would be better to be strict up front and relax it as flow control analysis becomes more mature.
>
> Well, I implemented it (https://github.com/dlang/dmd/pull/7375), but it's off to a pretty rocky start.
>
> Mike

To be honest, I didn't actually expect anyone to act on my question. :D
I was just more curious of the design decisions that were made.

On Wednesday, 29 November 2017 at 01:24:21 UTC, A Guy With a Question wrote:

> I was just more curious of the design decisions that were made.

So am I.  I'm trying to get to the heart of in the the PR comments.

Mike

On Wednesday, 29 November 2017 at 01:25:47 UTC, Michael V. Franklin wrote:
> On Wednesday, 29 November 2017 at 01:24:21 UTC, A Guy With a Question wrote:
>
>> I was just more curious of the design decisions that were made.
>
> So am I.  I'm trying to get to the heart of in the the PR comments.
>
> Mike

That's a lot less code than I would have thought to implement that. The comment about phobos was a good one. Just reading through it.

On Friday, 24 November 2017 at 14:30:44 UTC, A Guy With a Question wrote:
> I would have expected 0 to be the default value. What's the logic behind having them being NaN by default?
>
> https://dlang.org/spec/type.html


http://www.drdobbs.com/cpp/nans-just-dont-get-no-respect/240005723