www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DMD 1.017 release

reply Walter Bright <newshound1 digitalmars.com> writes:
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
Jun 26 2007
next sibling parent reply "Stewart Gordon" <smjg_1998 yahoo.com> writes:
"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.
Jun 26 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
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.
Jun 26 2007
parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
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
Jun 26 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
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.
Jun 26 2007
next sibling parent BCS <ao pathlink.com> writes:
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.)
 

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

vote++
Jun 26 2007
prev sibling next sibling parent "Chris Miller" <chris dprogramming.com> writes:
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 =3D 42;'?  Mayb=


 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.
Jun 26 2007
prev sibling parent reply "Stewart Gordon" <smjg_1998 yahoo.com> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:f5s1k1$iuk$1 digitalmars.com...
 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?

Good idea. It would also enable is(typeof(x.init)) to be used to test whether x's initializer is a compile-time constant. Don't know what practical use this would have though....
 I think that if CTFE fails, having it silently revert to the type.init, 
 would be frustratingly obscure behavior.

Agreed. Moreover, if they want the initializer of x's type, they can use typeof(x).init. So changing x.init to do the same not only alters the behaviour of existing code, but gains no real benefit in the process. Stewart.
Jun 26 2007
next sibling parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Stewart Gordon wrote:
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:f5s1k1$iuk$1 digitalmars.com...
 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?

Good idea. It would also enable is(typeof(x.init)) to be used to test whether x's initializer is a compile-time constant. Don't know what practical use this would have though....

I think it would be useful in relation to what you mention below...
 I think that if CTFE fails, having it silently revert to the 
 type.init, would be frustratingly obscure behavior.

Agreed. Moreover, if they want the initializer of x's type, they can use typeof(x).init. So changing x.init to do the same not only alters the behaviour of existing code, but gains no real benefit in the process. Stewart.

Bingo. So it gets my vote. And to explain the first comment: template TInit (alias var) { static if (is(typeof(var.init))) { const TInit = var .init; } else { const TInit = typeof(var).init; } } For those occasions where you want the old-style behavior for whatever reason. :) -- Chris Nicholson-Sauls
Jun 26 2007
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
I'm going to have to retreat from this. Andrei made an argument that if 
one had:

	struct S
	{
		static int foo;
	}

	S s = ...;
	assert(s.foo == S.foo);

then, analogously:

	T t = ...;
	assert(t.init == T.init);

should hold as well. Consistency is a strong argument.
Jun 26 2007
next sibling parent Georg Wrede <georg nospam.org> writes:
Walter Bright wrote:
 I'm going to have to retreat from this. Andrei made an argument that if 
 one had:
 
     struct S
     {
         static int foo;
     }
 
     S s = ...;
     assert(s.foo == S.foo);
 
 then, analogously:
 
     T t = ...;
     assert(t.init == T.init);
 
 should hold as well. Consistency is a strong argument.

Well, whatever you do, it'd be convenient to test for "equal to the init value". In other words, please let us compare _both_ to the "type init value" or (in other circumstances) to the "specific type init value", depending on our needs at the time.
Jun 30 2007
prev sibling parent reply Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
Walter Bright wrote:
 I'm going to have to retreat from this. Andrei made an argument that if
 one had:
 
     struct S
     {
         static int foo;
     }
 
     S s = ...;
     assert(s.foo == S.foo);
 
 then, analogously:
 
     T t = ...;
     assert(t.init == T.init);
 
 should hold as well. Consistency is a strong argument.

I have a lot of code which looks like: foo = foo.max; // sentinel value maybeChangeFoo(foo); if (foo == foo.init) // did foo change? Now I have to duplicate the sentinel value in the code, which can be very annoying, and bug-prone if I forget to change one of the two. I can't always use the same value: usually it'll be 0, foo.min, or foo.max. It depends on what maybeChangeFoo can change foo to. Regarding consistency, .init isn't a static property. If you have: struct S { int foo; } S s = ...; assert (s.foo == S.foo); // oops, an error since S doesn't have foo So there's already precedent for s.x not equaling typeof(s).x. If you really want s.init to not be context-dependent, make it invalid. It's very confusing for it to equal typeof(s).init. -- Remove ".doesnotlike.spam" from the mail address.
Jul 01 2007
parent Walter Bright <newshound1 digitalmars.com> writes:
Deewiant wrote:
 I have a lot of code which looks like:
 
 foo = foo.max; // sentinel value
 
 maybeChangeFoo(foo);
 
 if (foo == foo.init) // did foo change?
 
 Now I have to duplicate the sentinel value in the code, which can be very
 annoying, and bug-prone if I forget to change one of the two. I can't always
use
 the same value: usually it'll be 0, foo.min, or foo.max. It depends on what
 maybeChangeFoo can change foo to.

I understand, I had some code that did that too. The issue is I expect a steadily increasing use of generic code, and the inconsistency is going to cause future problems.
 Regarding consistency, .init isn't a static property. If you have:
 
 struct S {
 	int foo;
 }
 
 S s = ...;
 assert (s.foo == S.foo); // oops, an error since S doesn't have foo
 
 So there's already precedent for s.x not equaling typeof(s).x. If you really
 want s.init to not be context-dependent, make it invalid. It's very confusing
 for it to equal typeof(s).init.
 

Jul 02 2007
prev sibling next sibling parent reply =?ISO-8859-1?Q?Lu=EDs_Marques?= <luismarques+spam gmail.com> writes:
 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 :( -- Lus
Jun 26 2007
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Luís Marques wrote:
  > New/Changed Features
  >
  > Added __VENDOR__ and __VERSION__.

 
 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.
Jun 26 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Frits van Bommel wrote:
 Luís Marques wrote:
  > New/Changed Features
  >
  > Added __VENDOR__ and __VERSION__.

 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.
Jun 26 2007
next sibling parent =?UTF-8?B?THXDrXMgTWFycXVlcw==?= <luismarques+spam gmail.com> writes:
Walter Bright wrote:
 Frits van Bommel wrote:
 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.

Fair enough. I hadn't related it to std.compiler.
Jun 26 2007
prev sibling parent "Stewart Gordon" <smjg_1998 yahoo.com> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message
news:f5s1o4$iuk$2 digitalmars.com...
 Frits van Bommel wrote:

 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.

I'd just been wondering how you were going to make sure __VERSION__ stays up to date. On looking at the source, now I see.... Stewart.
Jun 27 2007
prev sibling parent reply Don Clugston <dac nospam.com.au> writes:
Walter Bright wrote:
 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

Fixed CFTE bug with e++ and e--.

What bug was that? It sounds important.
Jun 26 2007
parent Walter Bright <newshound1 digitalmars.com> writes:
Don Clugston wrote:
 Walter Bright wrote:
 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

>Fixed CFTE bug with e++ and e--. What bug was that? It sounds important.

Post inc and dec were screwed up by the interpreter. Yes, it's important <g>.
Jun 27 2007