A corresponding 2.001 should be out soon.

http://www.digitalmars.com/d/1.0/changelog.html

http://ftp.digitalmars.com/dmd.1.017.zip

"Walter Bright" <newshound1@digitalmars.com> wrote in message news:f5rmna$3101$1@digitalmars.com...
>A corresponding 2.001 should be out soon.
>
> http://www.digitalmars.com/d/1.0/changelog.html

"The .init property for a variable is now based on its type, not its initializer."

Why?

Stewart. 

Stewart Gordon wrote:
> "Walter Bright" <newshound1@digitalmars.com> wrote in message news:f5rmna$3101$1@digitalmars.com...
>> A corresponding 2.001 should be out soon.
>>
>> http://www.digitalmars.com/d/1.0/changelog.html
> 
> "The .init property for a variable is now based on its type, not its initializer."
> 
> Why?

Suppose:

	int f = random();

in other words, let's say the initializer was a runtime computation that changes every time it is computed. This causes problems because then:

	assert(f == f.init)

fails.

Walter Bright wrote:
> Stewart Gordon wrote:
>> "Walter Bright" <newshound1@digitalmars.com> wrote in message news:f5rmna$3101$1@digitalmars.com...
>>> A corresponding 2.001 should be out soon.
>>>
>>> http://www.digitalmars.com/d/1.0/changelog.html
>>
>> "The .init property for a variable is now based on its type, not its initializer."
>>
>> Why?
> 
> Suppose:
> 
>     int f = random();
> 
> in other words, let's say the initializer was a runtime computation that changes every time it is computed. This causes problems because then:
> 
>     assert(f == f.init)
> 
> fails.
> 

Valid logic, but what about the common case of 'int f = 42;'?  Maybe the rule should be that .init is either a /literal/ initializer's value, or a CTF initializer's value, or else the type's .init value.  (I can recall having once or twice relied on a variable's .init being something particular.)

-- Chris Nicholson-Sauls

> New/Changed Features
>
> Added __VENDOR__ and __VERSION__.
> The .init property for a variable is now based on its type, not its
> initializer.

I thought version 1.x would only fix bugs :(

--
Luís

Luís Marques wrote:
>  > New/Changed Features
>  >
>  > Added __VENDOR__ and __VERSION__.
[snip]
> 
> I thought version 1.x would only fix bugs :(

I'd say that one is a good way to fix the constantly recurring bug of std.compiler reporting the wrong information.

Chris Nicholson-Sauls wrote:
> Valid logic, but what about the common case of 'int f = 42;'?  Maybe the rule should be that .init is either a /literal/ initializer's value, or a CTF initializer's value, or else the type's .init value.  (I can recall having once or twice relied on a variable's .init being something particular.)

How about, if it isn't a compile time constant, then using .init is an error?

I think that if CTFE fails, having it silently revert to the type.init, would be frustratingly obscure behavior.

Frits van Bommel wrote:
> Luís Marques wrote:
>>  > New/Changed Features
>>  >
>>  > Added __VENDOR__ and __VERSION__.
> [snip]
>>
>> I thought version 1.x would only fix bugs :(
> 
> I'd say that one is a good way to fix the constantly recurring bug of std.compiler reporting the wrong information.

Yup <g>. I wanted to fix that blasted problem once and for all.

Reply to Walter,

> Chris Nicholson-Sauls wrote:
> 
>> Valid logic, but what about the common case of 'int f = 42;'?  Maybe
>> the rule should be that .init is either a /literal/ initializer's
>> value, or a CTF initializer's value, or else the type's .init value.
>> (I can recall having once or twice relied on a variable's .init being
>> something particular.)
>> 
> How about, if it isn't a compile time constant, then using .init is an
> error?
> 
> I think that if CTFE fails, having it silently revert to the
> type.init, would be frustratingly obscure behavior.
> 

vote++

On Tue, 26 Jun 2007 17:49:06 -0400, Walter Bright <newshound1@digitalmars.com> wrote:

> Chris Nicholson-Sauls wrote:
>> Valid logic, but what about the common case of 'int f = 42;'?  Maybe the rule should be that .init is either a /literal/ initializer's value, or a CTF initializer's value, or else the type's .init value.  (I can recall having once or twice relied on a variable's .init being something particular.)
>
> How about, if it isn't a compile time constant, then using .init is an error?
>

Yes, I was thinking about this. It would at least be pretty compatible with before and safer.

What about array literals? They're dynamic, but it seems like they could also work in init.