digitalmars.D.announce - DMD 1.017 release

Walter Bright (3/3) Jun 26 2007 A corresponding 2.001 should be out soon.

Stewart Gordon (6/8) Jun 26 2007 "The .init property for a variable is now based on its type, not its

Walter Bright (7/17) Jun 26 2007 Suppose:

Chris Nicholson-Sauls (7/30) Jun 26 2007 Valid logic, but what about the common case of 'int f = 42;'? Maybe the...

Walter Bright (5/10) Jun 26 2007 How about, if it isn't a compile time constant, then using .init is an

BCS (2/16) Jun 26 2007 vote++
Chris Miller (11/19) Jun 26 2007 e =
Stewart Gordon (10/20) Jun 26 2007 Good idea. It would also enable

Chris Nicholson-Sauls (10/36) Jun 26 2007 Bingo. So it gets my vote. And to explain the first comment:
Walter Bright (12/12) Jun 26 2007 I'm going to have to retreat from this. Andrei made an argument that if

Georg Wrede (6/23) Jun 30 2007 Well, whatever you do, it'd be convenient to test for "equal to the init...
Deewiant (20/37) Jul 01 2007 I have a lot of code which looks like:

Walter Bright (4/29) Jul 02 2007 I understand, I had some code that did that too. The issue is I expect a...

=?ISO-8859-1?Q?Lu=EDs_Marques?= (3/7) Jun 26 2007 I thought version 1.x would only fix bugs :(

Frits van Bommel (4/9) Jun 26 2007 I'd say that one is a good way to fix the constantly recurring bug of

Walter Bright (2/12) Jun 26 2007 Yup . I wanted to fix that blasted problem once and for all.

=?UTF-8?B?THXDrXMgTWFycXVlcw==?= (2/7) Jun 26 2007 Fair enough. I hadn't related it to std.compiler.
Stewart Gordon (6/10) Jun 27 2007

Don Clugston (2/8) Jun 26 2007 What bug was that? It sounds important.

Walter Bright (3/13) Jun 27 2007 Post inc and dec were screwed up by the interpreter. Yes, it's important...

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

"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

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

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

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

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.)
 

 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++

Jun 26 2007

"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=


e  =

 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

"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

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

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

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

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

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

=?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 :(

--
Lu�s

Jun 26 2007

Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:

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.

Jun 26 2007

Walter Bright <newshound1 digitalmars.com> writes:

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.

Jun 26 2007

=?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

"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:

<snip>
 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

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

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

D Programming

C/C++ Programming

Other

digitalmars.D.announce - DMD 1.017 release