www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - dmd 2.063 beta 5

reply Walter Bright <newshound2 digitalmars.com> writes:
Join the dmd beta mailing list to keep up with the betas. This one is pretty 
much good to go, unless something disastrous crops up.

http://ftp.digitalmars.com/dmd2beta.zip

Remaining regressions:

http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED
bug_status=REOPENED
May 21 2013
next sibling parent reply "kdmult" <kdmult ya.ru> writes:
On Tuesday, 21 May 2013 at 20:36:20 UTC, Walter Bright wrote:

 Join the dmd beta mailing list to keep up with the betas. This 
 one is pretty much good to go, unless something disastrous 
 crops up.

 http://ftp.digitalmars.com/dmd2beta.zip


windows/bin/d.chm was generated using version 2.058, so there is
no some new information there.
May 21 2013
parent "kdmult" <kdmult ya.ru> writes:
On Wednesday, 22 May 2013 at 04:45:57 UTC, kdmult wrote:

 On Tuesday, 21 May 2013 at 20:36:20 UTC, Walter Bright wrote:

 Join the dmd beta mailing list to keep up with the betas. This 
 one is pretty much good to go, unless something disastrous 
 crops up.

 http://ftp.digitalmars.com/dmd2beta.zip


 windows/bin/d.chm was generated using version 2.058, so there is
 no some new information there.


Actually, the documentation included into the archive is not 
up-to-date. It should be re-generated.
May 21 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-05-21 22:36, Walter Bright wrote:

 Join the dmd beta mailing list to keep up with the betas. This one is
 pretty much good to go, unless something disastrous crops up.

 http://ftp.digitalmars.com/dmd2beta.zip


All directories have executable permission set.

-- 
/Jacob Carlborg
May 22 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/22/2013 11:55 PM, Jacob Carlborg wrote:

 On 2013-05-21 22:36, Walter Bright wrote:

 Join the dmd beta mailing list to keep up with the betas. This one is
 pretty much good to go, unless something disastrous crops up.

 http://ftp.digitalmars.com/dmd2beta.zip


 All directories have executable permission set.


Is this the case with previous zips, or is it new for this one?
May 23 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-05-23 09:08, Walter Bright wrote:


 Is this the case with previous zips, or is it new for this one?


Never mind. It was my tool. I tried a different one and it's not 
executable there.

-- 
/Jacob Carlborg
May 23 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/23/2013 1:22 AM, Jacob Carlborg wrote:

 On 2013-05-23 09:08, Walter Bright wrote:


 Is this the case with previous zips, or is it new for this one?


 Never mind. It was my tool. I tried a different one and it's not executable
there.


Phew!
May 23 2013
prev sibling next sibling parent reply "Don" <turnyourkidsintocash nospam.com> writes:
On Tuesday, 21 May 2013 at 20:36:20 UTC, Walter Bright wrote:

 Join the dmd beta mailing list to keep up with the betas. This 
 one is pretty much good to go, unless something disastrous 
 crops up.

 http://ftp.digitalmars.com/dmd2beta.zip

 Remaining regressions:

 http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED


NO NO NO NO. I am violently opposed to this release.

This beta contains the worst language misfeature of all time. 
It's silently snuck in under the guise of a bugfix.


struct S
{
     const int x = 7;
     int y;
}

In previous releases, S.x was always 7.
But now, if you write

S s = S(5);

then x gets changed to 5.
This means that the const variable x has been initialized TWICE!

This new behaviour is counter-intuitive and introduces a horrible 
inconsistency.

This is totally different to what happens with module 
constructors (you get a compile error if you try to set a const 
global if it already has an initializer). Likewise, everywhere 
else in the language, when you see a const variable with an 
initializer, the initializer gives its value.


I think the only possible solution is to make it an error to 
provide a const or immutable member with an initializer.

If you are providing an initializer, you surely meant to make it 
'static const', and that is certainly true of all existing usages 
of it.

As far as I can tell, this new feature exists only to create 
bugs. No use cases for it have been given. I cannot imagine a 
case where using this feature would not be a bug.


Please do not release this beta.
May 23 2013
next sibling parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Thursday, 23 May 2013 at 09:05:02 UTC, Don wrote:

 This means that the const variable x has been initialized TWICE!


That's no different from non-const members.

struct Foo { int x = 1; }
Foo f = Foo(2); // f.x is 2

The initialiser is a default value if you don't provide one in 
the constructor. If you don't mark a variable as static then it 
is not static and needs to be initialised like any other member 
variable.



 This new behaviour is counter-intuitive and introduces a 
 horrible inconsistency.


It is exactly what happens in C++ and causes no confusion there.



 This is totally different to what happens with module 
 constructors (you get a compile error if you try to set a const 
 global if it already has an initializer).


In structs/classes, it is not an initialiser, it is a default 
value in case you don't provide a different value.



 As far as I can tell, this new feature exists only to create 
 bugs. No use cases for it have been given. I cannot imagine a 
 case where using this feature would not be a bug.


The use case is simple: to allow non-static const member 
variables.
May 23 2013
next sibling parent reply "Don" <turnyourkidsintocash nospam.com> writes:
On Thursday, 23 May 2013 at 10:17:00 UTC, Peter Alexander wrote:

 On Thursday, 23 May 2013 at 09:05:02 UTC, Don wrote:

 This means that the const variable x has been initialized 
 TWICE!


 That's no different from non-const members.


It's perfectly OK to modify a non-const member as many times as 
you like. That doesn't cause confusion.


 struct Foo { int x = 1; }
 Foo f = Foo(2); // f.x is 2

 The initialiser is a default value if you don't provide one in 
 the constructor. If you don't mark a variable as static then it 
 is not static and needs to be initialised like any other member 
 variable.


What gives you that idea? It's listed as an initializer in the 
spec.
It's implemented as an initializer in the compiler.



 This new behaviour is counter-intuitive and introduces a 
 horrible inconsistency.


 It is exactly what happens in C++ and causes no confusion there.


I don't think it's legal in C++:

struct S
{
   const int x = 5;
};

w.cpp:4:17: error: ISO C++ forbids initialization of member ‘x’ 
[-fpermissive]



 This is totally different to what happens with module 
 constructors (you get a compile error if you try to set a 
 const global if it already has an initializer).


 In structs/classes, it is not an initialiser, it is a default 
 value in case you don't provide a different value.



 As far as I can tell, this new feature exists only to create 
 bugs. No use cases for it have been given. I cannot imagine a 
 case where using this feature would not be a bug.


 The use case is simple: to allow non-static const member 
 variables.


Not correct. You've always been able to have non-static const 
member variables, as long as they have no initializer.

What this feature does, is allow you to add an initializer which 
is ignored.
May 23 2013
parent "TommiT" <tommitissari hotmail.com> writes:
On Thursday, 23 May 2013 at 13:01:25 UTC, Don wrote:

 I don't think it's legal in C++:

 struct S
 {
   const int x = 5;
 };

 w.cpp:4:17: error: ISO C++ forbids initialization of member ‘x’ 
 [-fpermissive]


That is legal C++11 code. The non-static data member initializer 
(=5) simply adds an implicit entry (if not present) for that 
particular data member to each constructor initialization list. 
Thus, the struct S above is the same as:

struct S
{
     const int x;

     S() : x (5) { }
};

The fact that the field is const doesn't play any significant 
role here.
May 23 2013
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/23/13 6:16 AM, Peter Alexander wrote:

 On Thursday, 23 May 2013 at 09:05:02 UTC, Don wrote:

 This means that the const variable x has been initialized TWICE!


 That's no different from non-const members.

 struct Foo { int x = 1; }
 Foo f = Foo(2); // f.x is 2

 The initialiser is a default value if you don't provide one in the
 constructor. If you don't mark a variable as static then it is not
 static and needs to be initialised like any other member variable.



 This new behaviour is counter-intuitive and introduces a horrible
 inconsistency.


 It is exactly what happens in C++ and causes no confusion there.



 This is totally different to what happens with module constructors
 (you get a compile error if you try to set a const global if it
 already has an initializer).


 In structs/classes, it is not an initialiser, it is a default value in
 case you don't provide a different value.



 As far as I can tell, this new feature exists only to create bugs. No
 use cases for it have been given. I cannot imagine a case where using
 this feature would not be a bug.


 The use case is simple: to allow non-static const member variables.


The point is, this is a silent change of behavior. (I agree the new 
behavior is sensible.)

Andrei
May 23 2013
prev sibling next sibling parent reply Artur Skawina <art.08.09 gmail.com> writes:
On 05/23/13 11:05, Don wrote:

 On Tuesday, 21 May 2013 at 20:36:20 UTC, Walter Bright wrote:

 Join the dmd beta mailing list to keep up with the betas. This one is pretty
much good to go, unless something disastrous crops up.

 http://ftp.digitalmars.com/dmd2beta.zip

 Remaining regressions:

 http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED


 
 NO NO NO NO. I am violently opposed to this release.
 
 This beta contains the worst language misfeature of all time. It's silently
snuck in under the guise of a bugfix.


It is a bugfix. It's also a breaking change, for code that relied on the buggy
behavior. There may be ways to ease the migration. But it's not a 'misfeature'.

The language changes with /every/ frontend release, often silently or with
just a note in some bugzilla entry.. This case isn't any worse and at least
this change is actually a real fix.

The scoped import change, which makes local imports effectively 'public' is a
much more serious problem. Undoing that one would be painful in the future,
if it were to stay. ( http://d.puremagic.com/issues/show_bug.cgi?id=10128 )



 struct S
 {
     const int x = 7;
     int y;
 }
 
 In previous releases, S.x was always 7.
 But now, if you write
 
 S s = S(5);
 
 then x gets changed to 5.
 This means that the const variable x has been initialized TWICE!
 
 This new behaviour is counter-intuitive and introduces a horrible
inconsistency.


Yes, this is wrong and just shouldn't be allowed. And, yes, even inside ctors.


 This is totally different to what happens with module constructors (you get a
compile error if you try to set a const global if it already has an
initializer). Likewise, everywhere else in the language, when you see a const
variable with an initializer, the initializer gives its value.


Yes, introducing a "const and initialized, but still mutable" class makes no
sense.


 I think the only possible solution is to make it an error to provide a const
or immutable member with an initializer.


Except for the issue mentioned above, the new behavior is right. Adding a
keyword ("static") to such declarations should not be a real problem.
AIUI the compiler can be made to list all the places which need changing.
But, yes, the fact that the old (buggy) code compiles, but now silently
drops that implicit "static" isn't ideal.
Would making 'struct S{const a=1;}" illegal for a release really be a
significant improvement? Any code not updated during that 'migration'
period would then still be in the same situation...


 If you are providing an initializer, you surely meant to make it 'static
const', and that is certainly true of all existing usages of it.
 As far as I can tell, this new feature exists only to create bugs. No use
cases for it have been given. I cannot imagine a case where using this feature
would not be a bug.


struct Packet(uint TYPE) {
   immutable uint type = TYPE;
   // ...
}

artur
May 23 2013
parent reply "Don" <turnyourkidsintocash nospam.com> writes:
On Thursday, 23 May 2013 at 11:08:16 UTC, Artur Skawina wrote:

 On 05/23/13 11:05, Don wrote:

 On Tuesday, 21 May 2013 at 20:36:20 UTC, Walter Bright wrote:

 Join the dmd beta mailing list to keep up with the betas. 
 This one is pretty much good to go, unless something 
 disastrous crops up.

 http://ftp.digitalmars.com/dmd2beta.zip

 Remaining regressions:

 http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED


 
 NO NO NO NO. I am violently opposed to this release.
 
 This beta contains the worst language misfeature of all time. 
 It's silently snuck in under the guise of a bugfix.


 It is a bugfix.


No. Disallowing the problematic initializer fixes the bug. 
Allowing it, but with a different meaning, is a new feature.



 It's also a breaking change, for code that relied on the buggy
 behavior. There may be ways to ease the migration. But it's not 
 a 'misfeature'.

 The language changes with /every/ frontend release, often 
 silently or with
 just a note in some bugzilla entry.. This case isn't any worse 
 and at least
 this change is actually a real fix.


No, it's not, it's a fix plus a new misfeature.


 The scoped import change, which makes local imports effectively 
 'public' is a
 much more serious problem. Undoing that one would be painful in 
 the future,
 if it were to stay. ( 
 http://d.puremagic.com/issues/show_bug.cgi?id=10128 )



 struct S
 {
     const int x = 7;
     int y;
 }
 
 In previous releases, S.x was always 7.
 But now, if you write
 
 S s = S(5);
 
 then x gets changed to 5.
 This means that the const variable x has been initialized 
 TWICE!
 
 This new behaviour is counter-intuitive and introduces a 
 horrible inconsistency.


 Yes, this is wrong and just shouldn't be allowed. And, yes, 
 even inside ctors.


 This is totally different to what happens with module 
 constructors (you get a compile error if you try to set a 
 const global if it already has an initializer). Likewise, 
 everywhere else in the language, when you see a const variable 
 with an initializer, the initializer gives its value.


 Yes, introducing a "const and initialized, but still mutable" 
 class makes no sense.


 I think the only possible solution is to make it an error to 
 provide a const or immutable member with an initializer.


 Except for the issue mentioned above, the new behavior is 
 right. Adding a
 keyword ("static") to such declarations should not be a real 
 problem.
 AIUI the compiler can be made to list all the places which need 
 changing.
 But, yes, the fact that the old (buggy) code compiles, but now 
 silently
 drops that implicit "static" isn't ideal.
 Would making 'struct S{const a=1;}" illegal for a release 
 really be a
 significant improvement? Any code not updated during that 
 'migration'
 period would then still be in the same situation...


No, it should be illegal for ever. It's not sensible behaviour.


 If you are providing an initializer, you surely meant to make 
 it 'static const', and that is certainly true of all existing 
 usages of it.
 As far as I can tell, this new feature exists only to create 
 bugs. No use cases for it have been given. I cannot imagine a 
 case where using this feature would not be a bug.


 struct Packet(uint TYPE) {
    immutable uint type = TYPE;
    // ...
 }


But that allows you to write:

auto w  = Packet!(7)(6);

which sets type to 6 !
That makes no sense. It's a bug. Probably you meant:

struct Packet(uint TYPE) {
     static immutable uint type = TYPE;
     // ...
}
which doesn't store a copy of the '7' in every instance.
May 23 2013
next sibling parent reply Artur Skawina <art.08.09 gmail.com> writes:
On 05/23/13 15:12, Don wrote:

 On Thursday, 23 May 2013 at 11:08:16 UTC, Artur Skawina wrote:

 On 05/23/13 11:05, Don wrote:

 On Tuesday, 21 May 2013 at 20:36:20 UTC, Walter Bright wrote:

 Join the dmd beta mailing list to keep up with the betas. This one is pretty
much good to go, unless something disastrous crops up.

 http://ftp.digitalmars.com/dmd2beta.zip

 Remaining regressions:

 http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED


 NO NO NO NO. I am violently opposed to this release.

 This beta contains the worst language misfeature of all time. It's silently
snuck in under the guise of a bugfix.


 It is a bugfix.


 
 No. Disallowing the problematic initializer fixes the bug. Allowing it, but
with a different meaning, is a new feature.
 
 

 It's also a breaking change, for code that relied on the buggy
 behavior. There may be ways to ease the migration. But it's not a 'misfeature'.

 The language changes with /every/ frontend release, often silently or with
 just a note in some bugzilla entry.. This case isn't any worse and at least
 this change is actually a real fix.


 
 No, it's not, it's a fix plus a new misfeature.
 

 The scoped import change, which makes local imports effectively 'public' is a
 much more serious problem. Undoing that one would be painful in the future,
 if it were to stay. ( http://d.puremagic.com/issues/show_bug.cgi?id=10128 )



 struct S
 {
     const int x = 7;
     int y;
 }

 In previous releases, S.x was always 7.
 But now, if you write

 S s = S(5);

 then x gets changed to 5.
 This means that the const variable x has been initialized TWICE!

 This new behaviour is counter-intuitive and introduces a horrible
inconsistency.


 Yes, this is wrong and just shouldn't be allowed. And, yes, even inside ctors.


 This is totally different to what happens with module constructors (you get a
compile error if you try to set a const global if it already has an
initializer). Likewise, everywhere else in the language, when you see a const
variable with an initializer, the initializer gives its value.


 Yes, introducing a "const and initialized, but still mutable" class makes no
sense.


 I think the only possible solution is to make it an error to provide a const
or immutable member with an initializer.


 Except for the issue mentioned above, the new behavior is right. Adding a
 keyword ("static") to such declarations should not be a real problem.
 AIUI the compiler can be made to list all the places which need changing.
 But, yes, the fact that the old (buggy) code compiles, but now silently
 drops that implicit "static" isn't ideal.
 Would making 'struct S{const a=1;}" illegal for a release really be a
 significant improvement? Any code not updated during that 'migration'
 period would then still be in the same situation...


 
 No, it should be illegal for ever. It's not sensible behaviour.
 

 If you are providing an initializer, you surely meant to make it 'static
const', and that is certainly true of all existing usages of it.
 As far as I can tell, this new feature exists only to create bugs. No use
cases for it have been given. I cannot imagine a case where using this feature
would not be a bug.


 struct Packet(uint TYPE) {
    immutable uint type = TYPE;
    // ...
 }


 
 But that allows you to write:
 
 auto w  = Packet!(7)(6);
 
 which sets type to 6 !


No, it doesn't - this is why the "const and initialized, but still mutable"
class
is a bad idea. Modifying already initialized immutable data needs to be
forbidden.

Yes, there are a few situation where it, in theory, can make sense - but given D
semantics (no "implicit" RT evaluation of initializers) I don't think special
casing them here is a good idea. Since even the "old" semantics (w/ the implicit
"static) didn't allow it, it would be better to start out conservatively, and
only allow the safe mutations if they turn out to be absolutely necessary. Which
right no I don't think they are.


 That makes no sense. It's a bug. 


'Packet!(7)(6);' should not compile, as it makes no sense - if I wanted
'Packet.type'
to be mutable, I wouldn't be doing this.


 Probably you meant:
 
 struct Packet(uint TYPE) {
     static immutable uint type = TYPE;
     // ...
 }
 which doesn't store a copy of the '7' in every instance.


No, I really meant to have a type with a constant field at a specific offset.

There is no reason to disallow this. It's just that the previously implicit
'static' makes the migration harder, I know. Also, the old semantics are not
expected by anyone new to the language - it was a source of bugs, often
subtle and misleading.

artur
May 23 2013
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 23 May 2013 09:50:28 -0400, Artur Skawina <art.08.09 gmail.com>  
wrote:


 On 05/23/13 15:12, Don wrote:

 On Thursday, 23 May 2013 at 11:08:16 UTC, Artur Skawina wrote:





 struct Packet(uint TYPE) {
    immutable uint type = TYPE;
    // ...
 }


 But that allows you to write:

 auto w  = Packet!(7)(6);

 which sets type to 6 !


 No, it doesn't - this is why the "const and initialized, but still  
 mutable" class
 is a bad idea. Modifying already initialized immutable data needs to be  
 forbidden.


There is a misconception here.  The data is not fully initialized when the  
ctor is called, it's just that the memory where the instance lives happens  
to have a bit pattern in it with the value 7 when the ctor gets it.

It's no different than a non-default initialized immutable being  
"initialized" to 0 first before you set it.  It's just you get to define  
the bit pattern instead of using 0.

In order to disable the behavior above, you have to disable the default  
ctor, define a non-default ctor, or generate using a static  
method/function.

-Steve
May 23 2013
parent reply Artur Skawina <art.08.09 gmail.com> writes:
On 05/23/13 16:02, Steven Schveighoffer wrote:

 On Thu, 23 May 2013 09:50:28 -0400, Artur Skawina <art.08.09 gmail.com> wrote:
 

 On 05/23/13 15:12, Don wrote:

 On Thursday, 23 May 2013 at 11:08:16 UTC, Artur Skawina wrote:




 

 struct Packet(uint TYPE) {
    immutable uint type = TYPE;
    // ...
 }


 But that allows you to write:

 auto w  = Packet!(7)(6);

 which sets type to 6 !


 No, it doesn't - this is why the "const and initialized, but still mutable"
class
 is a bad idea. Modifying already initialized immutable data needs to be
forbidden.


 
 There is a misconception here.  The data is not fully initialized when the
ctor is called, it's just that the memory where the instance lives happens to
have a bit pattern in it with the value 7 when the ctor gets it.
 
 It's no different than a non-default initialized immutable being "initialized"
to 0 first before you set it.  It's just you get to define the bit pattern
instead of using 0.
 
 In order to disable the behavior above, you have to disable the default ctor,
define a non-default ctor, or generate using a static method/function.


If it wasn't clear - it is about the _language_, not what some compiler
currently happens to do. Being able to mutate /initialized/ immutables
is a bad idea. IOW you should not be able to modify 'Packet.type' above.

Keep in mind that modifying Packet.type is illegal /right now/. Even from
a ctor or static-ctor. This does not need to change when such fields are
no longer always implicitly static. While allowing re-initialization
of immutables from a ctor is possible, it does not really give you much,
while weakening const. (eg by making CT evaluation of such fields impossible).

artur
May 23 2013
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 23 May 2013 11:36:00 -0400, Artur Skawina <art.08.09 gmail.com>  
wrote:


 If it wasn't clear - it is about the _language_, not what some compiler
 currently happens to do. Being able to mutate /initialized/ immutables
 is a bad idea. IOW you should not be able to modify 'Packet.type' above.


The immutable isn't initialized.  The memory it happens to be using before  
initialization happens to have the '7' bit pattern in it.

Once it is initialized, I agree it should be immutable from that point on.


 Keep in mind that modifying Packet.type is illegal /right now/. Even from
 a ctor or static-ctor. This does not need to change when such fields are
 no longer always implicitly static. While allowing re-initialization
 of immutables from a ctor is possible, it does not really give you much,
 while weakening const. (eg by making CT evaluation of such fields  
 impossible).


That's an issue of where Packet.type lives.  It doesn't live inside an  
instance right now, in the new version it does.

If Packet.type is not given an initializer, it's inside the instance and  
it (correctly IMO) can be modified inside a ctor until it is used.

These rules are perfectly consistent.

I don't see how they make CT evaluation impossible.

-Steve
May 23 2013
parent reply Artur Skawina <art.08.09 gmail.com> writes:
On 05/23/13 18:26, Steven Schveighoffer wrote:

 On Thu, 23 May 2013 11:36:00 -0400, Artur Skawina <art.08.09 gmail.com> wrote:
 

 If it wasn't clear - it is about the _language_, not what some compiler
 currently happens to do. Being able to mutate /initialized/ immutables
 is a bad idea. IOW you should not be able to modify 'Packet.type' above.


 
 The immutable isn't initialized.  The memory it happens to be using before
initialization happens to have the '7' bit pattern in it.
 
 Once it is initialized, I agree it should be immutable from that point on.


It's all about the definition. Again, I'll point out that the code that we're
talking about here *can not* exist right now - until now the compiler has not
allowed mutation. So this is about a /change/ to the language, and isn't really
related to fixing that implicit-static bug - it's just that once that change
is made it then becomes possible to support the in-ctor re-initialization
of immutable fields. Which isn't really all that useful, but carries a cost.



 Keep in mind that modifying Packet.type is illegal /right now/. Even from
 a ctor or static-ctor. This does not need to change when such fields are
 no longer always implicitly static. While allowing re-initialization
 of immutables from a ctor is possible, it does not really give you much,
 while weakening const. (eg by making CT evaluation of such fields impossible).


 
 That's an issue of where Packet.type lives.  It doesn't live inside an
instance right now, in the new version it does.
 
 If Packet.type is not given an initializer, it's inside the instance and it
(correctly IMO) can be modified inside a ctor until it is used.
 
 These rules are perfectly consistent.
 
 I don't see how they make CT evaluation impossible.


The old way meant that the value was statically known and could be accessed at
CT.
Allowing ctors to modify the fields means that the compiler can not make any
assumptions about the value. [1] Which affects CT and constant
folding/propagation
etc. For example you couldn't then do this:

struct Packet(uint TY) { /*...*/immutable uint type=TY; immutable ubyte
len=PLen(TY); /*...*/ }
auto PProcess(PT)(PT* p) { static if (p.type<128) if (p.type==42) sendp(p,
p.len*4); }

Even w/o the static-if it would be much less efficient. Yes, there are other
ways to achieve a similar effect, but they are significantly more complicated.

The most conservative approach is to initially disallow mutation from ctors -
this
restriction can always be lifted later and doing so does not affect any existing
program.
Treating 'const' differently from 'immutable' is also a possibility, and could
be a future option.

Then there's the issue of 'immutable one=1;' being very misleading; it certainly
would be misinterpreted often enough (by assuming that ODR applies here).


artur

[1] BTW, I'm wondering if these changes also affect module-level const/immutable
    members... No DMD here to test, though.
May 23 2013
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 23 May 2013 16:42:30 -0400, Artur Skawina <art.08.09 gmail.com>  
wrote:


 On 05/23/13 18:26, Steven Schveighoffer wrote:

 On Thu, 23 May 2013 11:36:00 -0400, Artur Skawina <art.08.09 gmail.com>  
 wrote:


 If it wasn't clear - it is about the _language_, not what some compiler
 currently happens to do. Being able to mutate /initialized/ immutables
 is a bad idea. IOW you should not be able to modify 'Packet.type'  
 above.


 The immutable isn't initialized.  The memory it happens to be using  
 before initialization happens to have the '7' bit pattern in it.

 Once it is initialized, I agree it should be immutable from that point  
 on.


 It's all about the definition. Again, I'll point out that the code that  
 we're
 talking about here *can not* exist right now - until now the compiler  
 has not
 allowed mutation.


compiles:

struct S
{
    const int x;
    this(int n)
    {
	x = n;
    }
}


 So this is about a /change/ to the language, and isn't really
 related to fixing that implicit-static bug - it's just that once that  
 change
 is made it then becomes possible to support the in-ctor re-initialization
 of immutable fields. Which isn't really all that useful, but carries a  
 cost.


The change to the language allows something that wasn't easily allowed  
before -- defining the pre-initialization bit pattern that is blitted to  
the const member.  Until now, the only way to have a const member that is  
ctor-initialized is to make it have the default bit pattern for that type.

Hm... I just figured out something interesting.  We can mimic the "new"  
behavior in old compilers by creating a type that has a different default  
initialization:

import std.stdio;
struct myInt
{
    int x = 7;
}

struct S
{
    const myInt m;
    this(int n)
    {
        m.x = n;
    }
}

void main()
{
    S s;
    auto s2 = S(5);
    writefln("%d %d", s.m.x, s2.m.x");
}

Output on 2.061:
7 5


 Keep in mind that modifying Packet.type is illegal /right now/. Even  
 from
 a ctor or static-ctor. This does not need to change when such fields  
 are
 no longer always implicitly static. While allowing re-initialization
 of immutables from a ctor is possible, it does not really give you  
 much,
 while weakening const. (eg by making CT evaluation of such fields  
 impossible).


 That's an issue of where Packet.type lives.  It doesn't live inside an  
 instance right now, in the new version it does.

 If Packet.type is not given an initializer, it's inside the instance  
 and it (correctly IMO) can be modified inside a ctor until it is used.

 These rules are perfectly consistent.

 I don't see how they make CT evaluation impossible.


 The old way meant that the value was statically known and could be  
 accessed at CT.


And it still can, as long as you *properly* declare it as static (as it  
should have been).


 Allowing ctors to modify the fields means that the compiler can not make  
 any
 assumptions about the value. [1] Which affects CT and constant  
 folding/propagation
 etc.


And it shouldn't be able to on a value that is different for every  
instance, but constant for that instance.  However, it can make  
assumptions based on the fact that it can't change.  For example:

writeln(x.constmember);
....
auto n = x.constmember + 5; // can assume constmember is the same as  
before.


 For example you couldn't then do this:

 struct Packet(uint TY) { /*...*/immutable uint type=TY; immutable ubyte  
 len=PLen(TY); /*...*/ }
 auto PProcess(PT)(PT* p) { static if (p.type<128) if (p.type==42)  
 sendp(p, p.len*4); }


static if(TY < 128) if(TY == 42) ....


 Even w/o the static-if it would be much less efficient. Yes, there are  
 other
 ways to achieve a similar effect, but they are significantly more  
 complicated.


No, you are using the WRONG tool for the job.  If you want to make  
compile-time decisions, don't use run-time constants.


 The most conservative approach is to initially disallow mutation from  
 ctors - this
 restriction can always be lifted later and doing so does not affect any  
 existing
 program.
 Treating 'const' differently from 'immutable' is also a possibility, and  
 could
 be a future option.


It's already allowed.  Disallowing it would break code.


 Then there's the issue of 'immutable one=1;' being very misleading; it  
 certainly
 would be misinterpreted often enough (by assuming that ODR applies here).


use enum for compile-time constants, or static if you need an addressable  
constant.  There is no loss of functionality here, only gains.


 [1] BTW, I'm wondering if these changes also affect module-level  
 const/immutable
     members... No DMD here to test, though.


Of course not, there is no changing of what is const and what is not.  All  
that is changing is whether a default-initialized member becomes a static  
member or not.  The original rules as to when a const value can be  
initialized still apply.

-Steve
May 23 2013
next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 23 May 2013 17:06:57 -0400, Steven Schveighoffer  
<schveiguy yahoo.com> wrote:


 On Thu, 23 May 2013 16:42:30 -0400, Artur Skawina <art.08.09 gmail.com>  
 wrote:



 For example you couldn't then do this:

 struct Packet(uint TY) { /*...*/immutable uint type=TY; immutable ubyte  
 len=PLen(TY); /*...*/ }
 auto PProcess(PT)(PT* p) { static if (p.type<128) if (p.type==42)  
 sendp(p, p.len*4); }


 static if(TY < 128) if(TY == 42) ....


Sorry, I realize this wouldn't work.  You must enum the TY in order to  
fetch it in PProcess, or declare type and len static.

But the point is still valid, you cannot use the runtime value of a member  
variable for const folding.

You can use both the runtime value to occupy space, and the compile-time  
value to do tests.  For instance:

struct Packet(uint TY) { enum type = TY;  private immutable _type = type;   
enum len = PLen(TY); private immutable _len = len; ...}

In the current compiler, it's pretty much impossible to do this, unless  
you use a trick like I outlined in the last post.

-Steve
May 23 2013
prev sibling parent reply Artur Skawina <art.08.09 gmail.com> writes:
On 05/23/13 23:06, Steven Schveighoffer wrote:

 On Thu, 23 May 2013 16:42:30 -0400, Artur Skawina <art.08.09 gmail.com> wrote:
 

 On 05/23/13 18:26, Steven Schveighoffer wrote:

 On Thu, 23 May 2013 11:36:00 -0400, Artur Skawina <art.08.09 gmail.com> wrote:


 If it wasn't clear - it is about the _language_, not what some compiler
 currently happens to do. Being able to mutate /initialized/ immutables
 is a bad idea. IOW you should not be able to modify 'Packet.type' above.


 The immutable isn't initialized.  The memory it happens to be using before
initialization happens to have the '7' bit pattern in it.

 Once it is initialized, I agree it should be immutable from that point on.


 It's all about the definition. Again, I'll point out that the code that we're
 talking about here *can not* exist right now - until now the compiler has not
 allowed mutation.


 
 compiles:
 
 struct S
 {
    const int x;
    this(int n)
    {
     x = n;
    }
 }


It's the 'const int x = 42;' case we're talking about. *That* one does not
compile and doesn't need to. It /could/, but I see no reason to allow this;
the one use case of default init that can be overridden by a ctor is not
enough, not even close.


 So this is about a /change/ to the language, and isn't really
 related to fixing that implicit-static bug - it's just that once that change
 is made it then becomes possible to support the in-ctor re-initialization
 of immutable fields. Which isn't really all that useful, but carries a cost.


 
 The change to the language allows something that wasn't easily allowed before
-- defining the pre-initialization bit pattern that is blitted to the const
member.  Until now, the only way to have a const member that is
ctor-initialized is to make it have the default bit pattern for that type.
 
 Hm... I just figured out something interesting.  We can mimic the "new"
behavior in old compilers by creating a type that has a different default
initialization:


Yes, obviously. It's less convenient, but does not have the problems of a
"run-time-immutable".



 Keep in mind that modifying Packet.type is illegal /right now/. Even from
 a ctor or static-ctor. This does not need to change when such fields are
 no longer always implicitly static. While allowing re-initialization
 of immutables from a ctor is possible, it does not really give you much,
 while weakening const. (eg by making CT evaluation of such fields impossible).


 That's an issue of where Packet.type lives.  It doesn't live inside an
instance right now, in the new version it does.

 If Packet.type is not given an initializer, it's inside the instance and it
(correctly IMO) can be modified inside a ctor until it is used.

 These rules are perfectly consistent.

 I don't see how they make CT evaluation impossible.


 The old way meant that the value was statically known and could be accessed at
CT.


 
 And it still can, as long as you *properly* declare it as static (as it should
have been).


Umm, no. It *can not* be static. Yes, you can create a proxy enum - it's how
it's done today, because there is no better way, but that means you then have to
handle it manually and the compiler does not get a chance to optimize based on
the static info.


 Allowing ctors to modify the fields means that the compiler can not make any
 assumptions about the value. [1] Which affects CT and constant
folding/propagation
 etc.


 
 And it shouldn't be able to on a value that is different for every instance,
but constant for that instance.  However, it can make assumptions based on the
fact that it can't change.  For example:
 
 writeln(x.constmember);
 ....
 auto n = x.constmember + 5; // can assume constmember is the same as before.


The whole point is that the value *isn't* different for any instance. If it /is/
then just omit the initializer and use the ctor(s). You can still have custom
defaults, using the approach you mentioned above.



 For example you couldn't then do this:

 struct Packet(uint TY) { /*...*/immutable uint type=TY; immutable ubyte
len=PLen(TY); /*...*/ }
 auto PProcess(PT)(PT* p) { static if (p.type<128) if (p.type==42) sendp(p,
p.len*4); }


 
 static if(TY < 128) if(TY == 42) ....
 

 Even w/o the static-if it would be much less efficient. Yes, there are other
 ways to achieve a similar effect, but they are significantly more complicated.


 
 No, you are using the WRONG tool for the job.  If you want to make
compile-time decisions, don't use run-time constants.


I'm using *exactly* the right tool. What you are suggesting is a work-around for
a language limitation. Which isn't necessary; it's perfectly fine to tell the
compiler 'this field is truly immutable and it's value is always X'. In fact
that's how it used to be, except that the compiler wrongly omitted such fields
when laying out the object. Fixing that does not automatically mean that they
have to be become less constant.



 The most conservative approach is to initially disallow mutation from ctors -
this
 restriction can always be lifted later and doing so does not affect any
existing
 program.
 Treating 'const' differently from 'immutable' is also a possibility, and could
 be a future option.


 
 It's already allowed.  Disallowing it would break code.


Can you show an example where assigning to an already *initialized* immutable
variable is allowed?...
Of course, except the one case we're discussing - inside a ctor (where it should
be (made) illegal, and the argument is only about whether this is a language or
implementation bug).



 Then there's the issue of 'immutable one=1;' being very misleading; it
certainly
 would be misinterpreted often enough (by assuming that ODR applies here).


 
 use enum for compile-time constants, or static if you need an addressable
constant.  There is no loss of functionality here, only gains.
 

 [1] BTW, I'm wondering if these changes also affect module-level
const/immutable
     members... No DMD here to test, though.


 
 Of course not, there is no changing of what is const and what is not.  All
that is changing is whether a default-initialized member becomes a static
member or not.  The original rules as to when a const value can be initialized
still apply.


The question is about things like being able to evaluate them at CT, mutate from
mod ctors etc. Changes at the module level have other implications, for example
for cyclic RT mod ctor deps.

artur
May 23 2013
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 23 May 2013 19:03:25 -0400, Artur Skawina <art.08.09 gmail.com>  
wrote:


 On 05/23/13 23:06, Steven Schveighoffer wrote:



 compiles:

 struct S
 {
    const int x;
    this(int n)
    {
     x = n;
    }
 }


 It's the 'const int x = 42;' case we're talking about. *That* one does  
 not
 compile and doesn't need to. It /could/, but I see no reason to allow  
 this;


My example is essentially:

const int x = 0;

It is default initialized to 0, and then the ctor can initialize it to  
something else.

To say that

const int x = 42;

is different is inconsistent.  Both are consts stored inside each  
instance, written by the compiler before the ctor is called.  Then the  
ctor is free to initialize them away from the default.

What you want is a feature that defines a struct field as always a certain  
value and NOT changeable, even in the ctor.  As far as I know, that does  
not exist in D, and seems specialized to protocol layouts (normally you do  
not want to waste memory with a field that never changes and is always  
known at compile-time).  As the initializer syntax already is taken, you  
will need a new syntax, or improve the optimizer to be able to prove this  
is the case.

-Steve
May 23 2013
parent reply Artur Skawina <art.08.09 gmail.com> writes:
On 05/24/13 02:33, Steven Schveighoffer wrote:

 On Thu, 23 May 2013 19:03:25 -0400, Artur Skawina <art.08.09 gmail.com> wrote:
 

 On 05/23/13 23:06, Steven Schveighoffer wrote:


 

 compiles:

 struct S
 {
    const int x;
    this(int n)
    {
     x = n;
    }
 }


 It's the 'const int x = 42;' case we're talking about. *That* one does not
 compile and doesn't need to. It /could/, but I see no reason to allow this;


 
 My example is essentially:
 
 const int x = 0;


Actually

   const x = int.init;

but these *are* different, and, again - currently the compiler will not allow
mutation - if you add that "= 0" part to your example above it will no longer
compile.
Hence, you are arguing for a change in behavior. And the arguments for that
are extremely weak. The goal should be to allow const initialization to happen
exactly once. The fact some compiler is currently unable to enforce the rules
[1]
is not a good argument - the situation will improve eventually. And reversing
such a change later would be harder, as it would break code that started to
rely on the new rules.

artur

[1] /a/ set of rules, even if different from the ones I'm talking about.
    That's a broader topic. In this specific case nothing /needs/ to change,
    so adjusting the definition (if there even is any) is an option.
May 24 2013
parent reply "Don" <turnyourkidsintocash nospam.com> writes:
On Friday, 24 May 2013 at 10:55:09 UTC, Artur Skawina wrote:

 On 05/24/13 02:33, Steven Schveighoffer wrote:

 On Thu, 23 May 2013 19:03:25 -0400, Artur Skawina 
 <art.08.09 gmail.com> wrote:
 

 On 05/23/13 23:06, Steven Schveighoffer wrote:


 

 compiles:

 struct S
 {
    const int x;
    this(int n)
    {
     x = n;
    }
 }


 It's the 'const int x = 42;' case we're talking about. *That* 
 one does not
 compile and doesn't need to. It /could/, but I see no reason 
 to allow this;


 
 My example is essentially:
 
 const int x = 0;




No, that's not the same.
const int w;
is the same syntax used in C++. It's a declaration without an 
initializer. It signals your intention to initialize it later.

Now, D does default-initialize everything, so that there really 
isn't any such thing as an uninitialized variable in D, but it 
still signals the intention that you will modify it later.

int is a misleading example since the default initializer is 0, 
and it's common for people to rely on that.
Better to use char or float, or a class, where the default 
initializer is not usable, and it's clearer that it's a bug to 
use it.


The only way I can understand this feature is that it is changing 
the meaning of initializers inside aggregates.

Previously, they were initializers. Now, they're not. They're 
setting the value of .init for the class.
And they use the same syntax which is used for actual 
initializers.

In the past, the compiler didn't check if you from set a field in 
a constructor, which you had already initialized with an 
initializer.
But, it didn't really matter.
With a const field, it makes a much bigger difference, since if 
an initializer was specified, the only way that the field can 
make sense is if you modify it somewhere else. So the initializer 
MUST be able to be overwritten.

This has lead us to this oddity that under the new regime,

const char c = 'e';

is setting the value of c, unless it is inside an aggregate, in 
which case it's not initializing c, it's just specifying what 
.init is for that struct.

So, it's overloading the syntax to mean two very different things.

---


 Hence, you are arguing for a change in behavior. And the 
 arguments for that
 are extremely weak. The goal should be to allow const 
 initialization to happen
 exactly once.


I agree. This is the crux of the argument.
Are you and I the the only ones who see that as a valuable 
property of the language? I'm astonished that others are so 
willing to sacrifice it.
May 24 2013
next sibling parent "TommiT" <tommitissari hotmail.com> writes:
On Friday, 24 May 2013 at 11:57:53 UTC, Don wrote:

 On Friday, 24 May 2013 at 10:55:09 UTC, Artur Skawina wrote:

 Hence, you are arguing for a change in behavior. And the 
 arguments for that
 are extremely weak. The goal should be to allow const 
 initialization to happen
 exactly once.


 I agree. This is the crux of the argument.
 Are you and I the the only ones who see that as a valuable 
 property of the language? I'm astonished that others are so 
 willing to sacrifice it.


If const variable initialization is allowed to happen exactly 
once, then you'd prevent more complex initializations like the 
following:

struct Test
{
     immutable int[] lut;
     immutable int cnt;

     this(int mod)
     {
         lut.length = 999;
         cnt = 0;
         size_t last = 0;

         foreach (i, ref e; lut)
         {
             if (i % mod == 0)
             {
                 e = 42;
                 ++cnt;
                 last = i;
             }
         }
         lut.length = last + 1;
     }
}
May 24 2013
prev sibling next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Friday, 24 May 2013 at 11:57:53 UTC, Don wrote:

 ...


I have finally understood your point about default initializer vs 
changing T.init :) It was not that easy because there are no 
similar terms in other languages. Anyway, it does make sense. 
Somehow separating concept of compile-time default for a type 
from default initialization of specific variable does make sense. 
This may be a good reason for CTFE-limited default constructor 
instead of current approach.
May 24 2013
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 24 May 2013 07:57:51 -0400, Don <turnyourkidsintocash nospam.com>  
wrote:


 On Friday, 24 May 2013 at 10:55:09 UTC, Artur Skawina wrote:

 On 05/24/13 02:33, Steven Schveighoffer wrote:

 On Thu, 23 May 2013 19:03:25 -0400, Artur Skawina  
 <art.08.09 gmail.com> wrote:


 On 05/23/13 23:06, Steven Schveighoffer wrote:



 compiles:

 struct S
 {
    const int x;
    this(int n)
    {
     x = n;
    }
 }


 It's the 'const int x = 42;' case we're talking about. *That* one  
 does not
 compile and doesn't need to. It /could/, but I see no reason to allow  
 this;


  My example is essentially:
  const int x = 0;




 No, that's not the same.
 const int w;
 is the same syntax used in C++. It's a declaration without an  
 initializer. It signals your intention to initialize it later.


This isn't C++.  C++ has implicit default constructors that are built  
using the given initializations.  D does it differently.


 Now, D does default-initialize everything, so that there really isn't  
 any such thing as an uninitialized variable in D, but it still signals  
 the intention that you will modify it later.

 int is a misleading example since the default initializer is 0, and it's  
 common for people to rely on that.
 Better to use char or float, or a class, where the default initializer  
 is not usable, and it's clearer that it's a bug to use it.


OK, how about this:

struct MyFloat
{
    float f = 0.0;
}

struct S
{
    const MyFloat x;
}

:P


 The only way I can understand this feature is that it is changing the  
 meaning of initializers inside aggregates.

 Previously, they were initializers. Now, they're not. They're setting  
 the value of .init for the class.


This was ALWAYS the case.

struct S
{
    int x = 5; // sets S.init.x to 5
}

You are not looking at the change correctly.  The change is simply,  
instead of const int x = 5 magically (and incorrectly) implying static, it  
doesn't.  Then it defaults to the same behavior as non-const member  
initializers -- it sets the .init value for the struct.  Previously, this  
was difficult to do, see my above example.


 And they use the same syntax which is used for actual initializers.


They use the same syntax that is used to dictate the init value for  
non-const members.


 In the past, the compiler didn't check if you from set a field in a  
 constructor, which you had already initialized with an initializer.
 But, it didn't really matter.
 With a const field, it makes a much bigger difference, since if an  
 initializer was specified, the only way that the field can make sense is  
 if you modify it somewhere else. So the initializer MUST be able to be  
 overwritten.

 This has lead us to this oddity that under the new regime,

 const char c = 'e';

 is setting the value of c, unless it is inside an aggregate, in which  
 case it's not initializing c, it's just specifying what .init is for  
 that struct.


As is the same (and always has been) for all instance member initializers.

char c = 'e';


 Hence, you are arguing for a change in behavior. And the arguments for  
 that
 are extremely weak. The goal should be to allow const initialization to  
 happen
 exactly once.


 I agree. This is the crux of the argument.
 Are you and I the the only ones who see that as a valuable property of  
 the language? I'm astonished that others are so willing to sacrifice it.


It's still available, just put static on the member, and it's the same as  
before.

-Steve
May 24 2013
parent reply "Dicebot" <m.strashun gmail.com> writes:
On Friday, 24 May 2013 at 13:46:49 UTC, Steven Schveighoffer 
wrote:

 This was ALWAYS the case.

 struct S
 {
    int x = 5; // sets S.init.x to 5
 }


As far as I understand Don, this behavior should be considered 
misleading too, it does not matter if variable is const or not. 
And that does have some sense, because you have initializer 
syntax which does not really initialize anything on its own, 
contrary to very same initializer syntax used with variable.

There is an option to prohibit initializers for struct member 
declarations at all and allow CTFE-able default constructors 
instead, but that would have been a major change.

It does not change the fact that old behavior was completely 
broken beyond imagination though.
May 24 2013
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 24 May 2013 09:54:20 -0400, Dicebot <m.strashun gmail.com> wrote:


 On Friday, 24 May 2013 at 13:46:49 UTC, Steven Schveighoffer wrote:

 This was ALWAYS the case.

 struct S
 {
    int x = 5; // sets S.init.x to 5
 }


 As far as I understand Don, this behavior should be considered  
 misleading too, it does not matter if variable is const or not. And that  
 does have some sense, because you have initializer syntax which does not  
 really initialize anything on its own, contrary to very same initializer  
 syntax used with variable.


Being able to dictate the .init data is very powerful and useful.  You  
can't remove that feature.

But the point I'm making is that the syntax IS consistent.  It just never  
worked before, because of the implicit 'static'

-Steve
May 24 2013
parent reply "Dicebot" <m.strashun gmail.com> writes:
On Friday, 24 May 2013 at 13:58:32 UTC, Steven Schveighoffer 
wrote:

 Being able to dictate the .init data is very powerful and 
 useful.  You can't remove that feature.


Sure, I completely agree, thus the idea adding of CTFE-able 
constructor which will become the T.init for structs.


 But the point I'm making is that the syntax IS consistent.  It 
 just never worked before, because of the implicit 'static'


No it is not. It never worked before because it was simply 
broken. Now it works properly from the point of spec, but it is 
inconsistent from the point of language design:

int x = 5; // can you tell without looking at scope if it really 
initializes x or just defines .init for aggregate?

Initializer syntax does not really make sense for non-static 
aggregate members at all, mutable or not.
May 24 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Friday, 24 May 2013 at 14:04:33 UTC, Dicebot wrote:

 On Friday, 24 May 2013 at 13:58:32 UTC, Steven Schveighoffer 
 wrote:

 Being able to dictate the .init data is very powerful and 
 useful.  You can't remove that feature.


 Sure, I completely agree, thus the idea adding of CTFE-able 
 constructor which will become the T.init for structs.


 But the point I'm making is that the syntax IS consistent.  It 
 just never worked before, because of the implicit 'static'


 No it is not. It never worked before because it was simply 
 broken. Now it works properly from the point of spec, but it is 
 inconsistent from the point of language design:

 int x = 5; // can you tell without looking at scope if it 
 really initializes x or just defines .init for aggregate?

 Initializer syntax does not really make sense for non-static 
 aggregate members at all, mutable or not.


They define a default value for the field. The constructor can 
override it. It is expected that a constructor is able to 
construct an object.
May 24 2013
parent "Dicebot" <m.strashun gmail.com> writes:
On Saturday, 25 May 2013 at 05:32:28 UTC, deadalnix wrote:

 They define a default value for the field. The constructor can 
 override it. It is expected that a constructor is able to 
 construct an object.


Yes, I know. Actually, I have been saying it earlier in this 
topic. So what? :)
May 26 2013
prev sibling parent reply "TommiT" <tommitissari hotmail.com> writes:
On Friday, 24 May 2013 at 13:54:21 UTC, Dicebot wrote:

 There is an option to prohibit initializers for struct member 
 declarations at all and allow CTFE-able default constructors 
 instead, but that would have been a major change.


I don't see a reason why we couldn't have both ways (1. member 
initializers and 2. CTFE-able default constructor) for defining 
the init state of structs. Probably the sensible thing would be 
to make all member initializers illegal iff a default constructor 
has been defined for a struct. I'd be interested in seeing a 
proper feature request discussion about this in a dedicated forum 
or at bugzilla.
May 27 2013
parent "Dicebot" <m.strashun gmail.com> writes:
On Monday, 27 May 2013 at 07:32:15 UTC, TommiT wrote:

 I don't see a reason why we couldn't have both ways (1. member 
 initializers and 2. CTFE-able default constructor) for defining 
 the init state of structs. Probably the sensible thing would be 
 to make all member initializers illegal iff a default 
 constructor has been defined for a struct. I'd be interested in 
 seeing a proper feature request discussion about this in a 
 dedicated forum or at bugzilla.


Well, technically we can, of course, it won't be that different 
from current situation (even more confusing though). Consistency 
issue Don has convinced me about though is that can't be such 
thing as "member initializer" for non-static members, as there is 
nothing to initialize there. Initialization happens when variable 
is created and that is defined by combination of T.init, struct 
literal syntax and constructors. So, contrary to usual local 
variable use case, the very same "member initializer" syntax does 
not really initialize anything, it just changes T.init value.

I don't feel it is important enough to actually change anything 
but worth remembering as language design nitpick.
May 27 2013
prev sibling next sibling parent reply "Dicebot" <m.strashun gmail.com> writes:
something I may have actually used in real code writing a 
low-level networking library:

struct Packet
{
	immutable etherType = 0x0800; // IPv4 by default;
	
	// ...
	
	this(bool IPv6)
	{
		if (!IPv6)
			return; // fine with default, same as Packet.init
		else
		{
			etherType = 0x86DD;
			// ...
		}
	}
}

void main()
{
	auto buffer = cast(ubyte[])(Packet(true));
}
May 23 2013
next sibling parent reply Rory McGuire <rjmcguire gmail.com> writes:
On Thu, May 23, 2013 at 4:42 PM, Dicebot <m.strashun gmail.com> wrote:


 something I may have actually used in real code writing a low-level
 networking library:


...


default template argument would sort that out wouldn't it?



 May 23 2013



  parent reply "Dicebot" <m.strashun gmail.com>  writes:


On Thursday, 23 May 2013 at 14:56:14 UTC, Rory McGuire wrote:

 On Thu, May 23, 2013 at 4:42 PM, Dicebot <m.strashun gmail.com> 
 wrote:


 something I may have actually used in real code writing a 
 low-level
 networking library:


 ...


 default template argument would sort that out wouldn't it?


a) at the cost of unneeded template bloat
b) it requires to know your argument at compile-time. What if you 
packet construction is based on some text configuration file?



 May 23 2013



  parent reply Rory McGuire <rjmcguire gmail.com>  writes:


On Thu, May 23, 2013 at 5:06 PM, Dicebot <m.strashun gmail.com> wrote:


 On Thursday, 23 May 2013 at 14:56:14 UTC, Rory McGuire wrote:


 On Thu, May 23, 2013 at 4:42 PM, Dicebot <m.strashun gmail.com> wrote:


 b) it requires to know your argument at compile-time. What if you packet
 construction is based on some text configuration file?


:) I'm sure we could think of something wrong with any part of the language
if we really wanted to.



 May 23 2013



  parent reply "Dicebot" <m.strashun gmail.com>  writes:


On Thursday, 23 May 2013 at 15:15:18 UTC, Rory McGuire wrote:

 b) it requires to know your argument at compile-time. What if 
 you packet
 construction is based on some text configuration file?


 :) I'm sure we could think of something wrong with any part of 
 the language
 if we really wanted to.


Well, you see, I am not imagining it. Had to write a barebone 
traffic generation tool in C several months ago for project. It 
did almost exactly that, only with no help support from type 
system, of course.



 May 23 2013



  parent  Rory McGuire <rjmcguire gmail.com>  writes:


On Thu, May 23, 2013 at 5:24 PM, Dicebot <m.strashun gmail.com> wrote:


 On Thursday, 23 May 2013 at 15:15:18 UTC, Rory McGuire wrote:


 b) it requires to know your argument at compile-time. What if you packet

 construction is based on some text configuration file?


 :) I'm sure we could think of something wrong with any part of the
 language
 if we really wanted to.


 Well, you see, I am not imagining it. Had to write a barebone traffic
 generation tool in C several months ago for project. It did almost exactly
 that, only with no help support from type system, of course.


Hence the smile. It is a valid case as are most valid cases :) but We're
discussing which of the two happens more often. I think this is rare enough
to type an extra "!". In Go they would probably make it illegal, simply
because its confusing for most cases.



 May 23 2013



prev sibling next sibling parent reply "Don" <turnyourkidsintocash nospam.com>  writes:


On Thursday, 23 May 2013 at 14:42:27 UTC, Dicebot wrote:

 something I may have actually used in real code writing a 
 low-level networking library:

 struct Packet
 {
 	immutable etherType = 0x0800; // IPv4 by default;
 	
 	// ...
 	
 	this(bool IPv6)
 	{
 		if (!IPv6)
 			return; // fine with default, same as Packet.init
 		else
 		{
 			etherType = 0x86DD;
 			// ...
 		}
 	}
 }

 void main()
 {
 	auto buffer = cast(ubyte[])(Packet(true));
 }


That's better, but it's still not a convincing example.

I don't see why you cannot remove the intializer, and write:

this(bool IPv6)
{
     if (!IPv6)
       etherType = 0x0800;
     else
       etherType = 0x86DD;
   ...
}

That only leaves the case where you are bypassing the constructor.
If you have a constructor, but have just used Packet.init, the 
object is not constructed properly. I cannot see the value in 
having etherType initialized and everything else not.



 May 23 2013



  parent  "Dicebot" <m.strashun gmail.com>  writes:


On Thursday, 23 May 2013 at 16:01:56 UTC, Don wrote:

 That's better, but it's still not a convincing example.

 I don't see why you cannot remove the intializer, and write:

 this(bool IPv6)
 {
     if (!IPv6)
       etherType = 0x0800;
     else
       etherType = 0x86DD;
   ...
 }


Because then you will have an invalid default-initialized state. 
For example, in my case static array of Packets can be declared 
and I am guaranteed to have a properly initialized packet 
templates there (constructor can't be used obviously). Now after 
some thinking I favor template-based approach specifically for 
this task but general principle should be clear.


 That only leaves the case where you are bypassing the 
 constructor.


Not "by-passing", more like "not getting to". That it is one of 
subtle and incredibly awesome D features - T.init


 If you have a constructor, but have just used Packet.init, the 
 object is not constructed properly. I cannot see the value in 
 having etherType initialized and everything else not.


I have not mentioned other fields but they are expected to be 
initialized too, thanks to CTFE (don't know how it inter-operates 
with unions in current DMD though). So Packet.init here becomes 
_completely constructed_ Packet with defaults computed at 
compile-time.



 May 24 2013



prev sibling  parent reply Leandro Lucarella <luca llucax.com.ar>  writes:


Dicebot, el 23 de May a las 16:42 me escribiste:

 something I may have actually used in real code writing a low-level
 networking library:
 
 struct Packet
 {
 	immutable etherType = 0x0800; // IPv4 by default;
 	
 	// ...
 	
 	this(bool IPv6)
 	{
 		if (!IPv6)
 			return; // fine with default, same as Packet.init
 		else
 		{
 			etherType = 0x86DD;
 			// ...
 		}
 	}
 }


You can achieve the same with:

		if (!IPv6)
			etherType = 0x0800;
		else
			...

There is no need to double-initialize a immutable value. If you want to
make it more explicit, just use something like:

enum defaultEtherType = 0x0800;

                if (!IPv6)
                        etherType = defaultEtherType;
                else
                        ...

I don't think that very rare use case, which is perfectly covered by
this "workaround" justifies the complexity added by this
double-initialization. Also code review becomes a nightmare, when I see
immutable something = 1; I can't assume something will be always 1,
I have to take a look at the whole code looking for constructors. That
SUCKS.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Pa' ella cociné, pa' ella lavé, pa' ella soñe
Paella completa, $2,50
Pero, la luz mala me tira, y yo? yo soy ligero pa'l trote
La luz buena, está en el monte, allá voy, al horizonte



 May 27 2013



  parent  "Dicebot" <m.strashun gmail.com>  writes:


On Monday, 27 May 2013 at 17:08:19 UTC, Leandro Lucarella wrote:

 You can achieve the same with:

 		if (!IPv6)
 			etherType = 0x0800;
 		else
 			...

 There is no need to double-initialize a immutable value.


As I have already answered to Don it is all about T.init - only 
way to change it currently is to use initalizer syntax. It is 
hardly an issue with this use case - more like the general issue 
that such syntax was chosen for something that does not mean 
initialization.



 May 27 2013



prev sibling  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 5/23/13 9:12 AM, Don wrote:

 No, it's not, it's a fix plus a new misfeature.


Don, you're wrong. The feature is sensible. The problem with it is that 
it changes semantics of existing code.

Andrei



 May 23 2013



  parent  Leandro Lucarella <luca llucax.com.ar>  writes:


Andrei Alexandrescu, el 23 de May a las 12:57 me escribiste:

 On 5/23/13 9:12 AM, Don wrote:

No, it's not, it's a fix plus a new misfeature.


 
 Don, you're wrong. The feature is sensible. The problem with it is
 that it changes semantics of existing code.


Is not sensible for code review. For me the price to pay for a feature
that add so little is too high. ROI ;)

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Un paracaidista, que no deja de caer.
Lo que me lleva hacia arriba, es lo que me tira hacia abajo.



 May 27 2013



prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Thu, 23 May 2013 05:05:01 -0400, Don <turnyourkidsintocash nospam.com>  
wrote:


 On Tuesday, 21 May 2013 at 20:36:20 UTC, Walter Bright wrote:

 Join the dmd beta mailing list to keep up with the betas. This one is  
 pretty much good to go, unless something disastrous crops up.

 http://ftp.digitalmars.com/dmd2beta.zip

 Remaining regressions:

 http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED


 NO NO NO NO. I am violently opposed to this release.

 This beta contains the worst language misfeature of all time. It's  
 silently snuck in under the guise of a bugfix.


 struct S
 {
      const int x = 7;
      int y;
 }

 In previous releases, S.x was always 7.
 But now, if you write

 S s = S(5);

 then x gets changed to 5.
 This means that the const variable x has been initialized TWICE!



 This new behaviour is counter-intuitive and introduces a horrible  
 inconsistency.


I disagree.

struct S
{
      const int x;
}

S s1; // x is 0
S s2 = S(5); // x is 5

Adding an initializer simply changes the default value from 0 to whatever  
you want.  It's quite consistent IMO.

The issue you are having is that the old behavior that you rely on is  
inconsistent.  I agree that this is a large problem, especially if you  
have code like you wrote, which likely expects to set y and not x!


 This is totally different to what happens with module constructors (you  
 get a compile error if you try to set a const global if it already has  
 an initializer). Likewise, everywhere else in the language, when you see  
 a const variable with an initializer, the initializer gives its value.


Module constructors are totally inconsistent with struct/class  
constructors, and have been for some time.  One doesn't "call" a module  
constructor, it's implicitly called.  The semantics are totally  
different.  It also makes no sense to set a value to something different,  
because there isn't more than one instance of the module.  It will be set  
to one value and that's it.


 I think the only possible solution is to make it an error to provide a  
 const or immutable member with an initializer.


This would be my recommendation:

1. Make the above an error.  It is not good to allow code with changed  
semantics to silently compile without intervention.
2. Disable the error with a switch (to allow for the new behavior).
3. In a future release, remove the error.


 If you are providing an initializer, you surely meant to make it 'static  
 const', and that is certainly true of all existing usages of it.

 As far as I can tell, this new feature exists only to create bugs. No  
 use cases for it have been given. I cannot imagine a case where using  
 this feature would not be a bug.


I can see uses.  If you don't want x.init to be the default for x, then  
you need to set it to something else.

For example:

struct Widget
{
    immutable string name = "(unset)"; // instead of ""
}

-Steve



 May 23 2013



 next sibling parent reply Iain Buclaw <ibuclaw ubuntu.com>  writes:


On 23 May 2013 14:52, Steven Schveighoffer <schveiguy yahoo.com> wrote:

 On Thu, 23 May 2013 05:05:01 -0400, Don <turnyourkidsintocash nospam.com>
 wrote:


 On Tuesday, 21 May 2013 at 20:36:20 UTC, Walter Bright wrote:

 Join the dmd beta mailing list to keep up with the betas. This one is
 pretty much good to go, unless something disastrous crops up.

 http://ftp.digitalmars.com/dmd2beta.zip

 Remaining regressions:


 http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED



 NO NO NO NO. I am violently opposed to this release.

 This beta contains the worst language misfeature of all time. It's
 silently snuck in under the guise of a bugfix.


 struct S
 {
      const int x = 7;
      int y;
 }

 In previous releases, S.x was always 7.
 But now, if you write

 S s = S(5);

 then x gets changed to 5.
 This means that the const variable x has been initialized TWICE!




 This new behaviour is counter-intuitive and introduces a horrible
 inconsistency.



 I disagree.

 struct S
 {
      const int x;
 }

 S s1; // x is 0
 S s2 = S(5); // x is 5

 Adding an initializer simply changes the default value from 0 to whatever
 you want.  It's quite consistent IMO.


Don't think it makes sense in non-POD structs...

Haven't tested, but is this an error?

struct S
{
    const int;

    this (int x)
    {
        this.x = x;    // here
    }
}

S(5);


Regards
--
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';



 May 23 2013



  parent reply "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Thu, 23 May 2013 10:16:13 -0400, Iain Buclaw <ibuclaw ubuntu.com> wrote:


 On 23 May 2013 14:52, Steven Schveighoffer <schveiguy yahoo.com> wrote:



 Adding an initializer simply changes the default value from 0 to  
 whatever
 you want.  It's quite consistent IMO.


 Don't think it makes sense in non-POD structs...

 Haven't tested, but is this an error?

 struct S
 {
     const int;

     this (int x)
     {
         this.x = x;    // here
     }
 }

 S(5);


Well, since you didn't name the member, it didn't compile right off :)

But after I fixed that, it does compile, both on 2.061 and the beta.

However, there is definitely a bug somewhere, this compiles:

struct S
{
     const int x;
     int y;

     this (int x)
     {
         y = this.x;
         writeln(this.y);
         this.x = x;
         writeln(this.x);
         this.x = 0;
         writeln(this.x);
     }
}

outputs:
0
5
0

Seems like const qualifier for members is simply ignored inside the ctor,  
it should only be ignored until it is set, or until it is used.

-Steve



 May 23 2013



 next sibling parent  Rory McGuire <rjmcguire gmail.com>  writes:


On Thu, May 23, 2013 at 4:57 PM, Steven Schveighoffer
<schveiguy yahoo.com>wrote:


 Seems like const qualifier for members is simply ignored inside the ctor,
 it should only be ignored until it is set, or until it is used.


Is that perhaps to help with building strings, arrays etc...



 May 23 2013



prev sibling next sibling parent reply "Dicebot" <m.strashun gmail.com>  writes:


On Thursday, 23 May 2013 at 14:58:01 UTC, Steven Schveighoffer 
wrote:

 Seems like const qualifier for members is simply ignored inside 
 the ctor, it should only be ignored until it is set, or until 
 it is used.


I am quite sure I have seen it (mutability of immutable in 
constructor) guaranteed either by spec or TDPL. Don't have TDPL 
with me right now, need to check later.



 May 23 2013



 next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Thu, 23 May 2013 11:07:16 -0400, Dicebot <m.strashun gmail.com> wrote:


 On Thursday, 23 May 2013 at 14:58:01 UTC, Steven Schveighoffer wrote:

 Seems like const qualifier for members is simply ignored inside the  
 ctor, it should only be ignored until it is set, or until it is used.


 I am quite sure I have seen it (mutability of immutable in constructor)  
 guaranteed either by spec or TDPL. Don't have TDPL with me right now,  
 need to check later.


I did check, though not thoroughly.  I think it only talks about actual  
immutable constructors (that is, initializing a fully immutable-qualified  
instance).  It doesn't really talk about immutable members.

And for immutable constructors, the rule seems to be that you can assign  
fields as many times as you want, but you cannot read them, or call any  
methods.

I think whatever rules are used, they should be consistent for  
immutable/const members as well.

-Steve



 May 23 2013



  parent  "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Thu, 23 May 2013 11:14:47 -0400, Steven Schveighoffer  
<schveiguy yahoo.com> wrote:


 On Thu, 23 May 2013 11:07:16 -0400, Dicebot <m.strashun gmail.com> wrote:


 On Thursday, 23 May 2013 at 14:58:01 UTC, Steven Schveighoffer wrote:

 Seems like const qualifier for members is simply ignored inside the  
 ctor, it should only be ignored until it is set, or until it is used.


 I am quite sure I have seen it (mutability of immutable in constructor)  
 guaranteed either by spec or TDPL. Don't have TDPL with me right now,  
 need to check later.


 I did check, though not thoroughly.  I think it only talks about actual  
 immutable constructors (that is, initializing a fully  
 immutable-qualified instance).  It doesn't really talk about immutable  
 members.

 And for immutable constructors, the rule seems to be that you can assign  
 fields as many times as you want, but you cannot read them, or call any  
 methods.

 I think whatever rules are used, they should be consistent for  
 immutable/const members as well.


Actually, this is a bad idea.  TDPL may need to be invalidated here.

If this was followed, then normal mutable ctors would become as limited as  
immutable ctors because they would have to follow the same rules (no  
calling other methods).

I still think it should be consistent between both things (immutable ctors  
and initializing immutable data).

I'll post a thread on standard NG.

-Steve



 May 23 2013



prev sibling  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 5/23/13 11:07 AM, Dicebot wrote:

 On Thursday, 23 May 2013 at 14:58:01 UTC, Steven Schveighoffer wrote:

 Seems like const qualifier for members is simply ignored inside the
 ctor, it should only be ignored until it is set, or until it is used.


 I am quite sure I have seen it (mutability of immutable in constructor)
 guaranteed either by spec or TDPL. Don't have TDPL with me right now,
 need to check later.


TDPL 8.4 discusses a raw/cooked model of construction. The same 
principle should apply to const/immutable member construction: you get 
to cook the field, but you can't taste it while raw.

The presence of an initializer with the immutable/const member 
declaration serves as a default in case the member is not explicitly 
initialized.


Andrei



 May 23 2013



  parent reply Marco Leise <Marco.Leise gmx.de>  writes:


Am Thu, 23 May 2013 13:06:44 -0400
schrieb Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>:


 TDPL 8.4 discusses a raw/cooked model of construction. The same 
 principle should apply to const/immutable member construction: you get 
 to cook the field, but you can't taste it while raw.


You are not making friends with Japanese D users.

-- 
Marco



 May 23 2013



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 5/23/13 2:08 PM, Marco Leise wrote:

 Am Thu, 23 May 2013 13:06:44 -0400
 schrieb Andrei Alexandrescu<SeeWebsiteForEmail erdani.org>:


 TDPL 8.4 discusses a raw/cooked model of construction. The same
 principle should apply to const/immutable member construction: you get
 to cook the field, but you can't taste it while raw.


 You are not making friends with Japanese D users.


Good one! And incidentally I love sashimi :o). Well let me amend it: if 
your plan is to cook it, don't taste it before.

Andrei



 May 23 2013



  parent reply "Regan Heath" <regan netmail.co.nz>  writes:


On Thu, 23 May 2013 19:52:14 +0100, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 On 5/23/13 2:08 PM, Marco Leise wrote:

 Am Thu, 23 May 2013 13:06:44 -0400
 schrieb Andrei Alexandrescu<SeeWebsiteForEmail erdani.org>:


 TDPL 8.4 discusses a raw/cooked model of construction. The same
 principle should apply to const/immutable member construction: you get
 to cook the field, but you can't taste it while raw.


 You are not making friends with Japanese D users.


 Good one! And incidentally I love sashimi :o). Well let me amend it: if  
 your plan is to cook it, don't taste it before.


mmm cookie dough/cake batter. :p

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/



 May 24 2013



  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 5/24/13 5:09 AM, Regan Heath wrote:

 On Thu, 23 May 2013 19:52:14 +0100, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:


 On 5/23/13 2:08 PM, Marco Leise wrote:

 Am Thu, 23 May 2013 13:06:44 -0400
 schrieb Andrei Alexandrescu<SeeWebsiteForEmail erdani.org>:


 TDPL 8.4 discusses a raw/cooked model of construction. The same
 principle should apply to const/immutable member construction: you get
 to cook the field, but you can't taste it while raw.


 You are not making friends with Japanese D users.


 Good one! And incidentally I love sashimi :o). Well let me amend it:
 if your plan is to cook it, don't taste it before.


 mmm cookie dough/cake batter. :p


I'm officially pwned.

Andrei



 May 24 2013



prev sibling  parent  "Iain Buclaw" <ibuclaw ubuntu.com>  writes:


On Thursday, 23 May 2013 at 14:58:01 UTC, Steven Schveighoffer 
wrote:

 On Thu, 23 May 2013 10:16:13 -0400, Iain Buclaw 
 <ibuclaw ubuntu.com> wrote:


 On 23 May 2013 14:52, Steven Schveighoffer 
 <schveiguy yahoo.com> wrote:



 Adding an initializer simply changes the default value from 0 
 to whatever
 you want.  It's quite consistent IMO.


 Don't think it makes sense in non-POD structs...

 Haven't tested, but is this an error?

 struct S
 {
    const int;

    this (int x)
    {
        this.x = x;    // here
    }
 }

 S(5);


 Well, since you didn't name the member, it didn't compile right 
 off :)


Yeah... I've had little sleep so I'm not with it. =)



 May 23 2013



prev sibling  parent reply "Don" <turnyourkidsintocash nospam.com>  writes:


On Thursday, 23 May 2013 at 13:52:49 UTC, Steven Schveighoffer 
wrote:

 On Thu, 23 May 2013 05:05:01 -0400, Don 
 <turnyourkidsintocash nospam.com> wrote:


 On Tuesday, 21 May 2013 at 20:36:20 UTC, Walter Bright wrote:

 Join the dmd beta mailing list to keep up with the betas. 
 This one is pretty much good to go, unless something 
 disastrous crops up.

 http://ftp.digitalmars.com/dmd2beta.zip

 Remaining regressions:

 http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED


 NO NO NO NO. I am violently opposed to this release.

 This beta contains the worst language misfeature of all time. 
 It's silently snuck in under the guise of a bugfix.


 struct S
 {
     const int x = 7;
     int y;
 }

 In previous releases, S.x was always 7.
 But now, if you write

 S s = S(5);

 then x gets changed to 5.
 This means that the const variable x has been initialized 
 TWICE!



 This new behaviour is counter-intuitive and introduces a 
 horrible inconsistency.


 I disagree.

 struct S
 {
      const int x;
 }

 S s1; // x is 0



Of course! It's an uninitialized variable! Try making x a float, 
and you'll get NaN.


 S s2 = S(5); // x is 5


---

 I can see uses.  If you don't want x.init to be the default for 
 x, then you need to set it to something else.

 For example:

 struct Widget
 {
    immutable string name = "(unset)"; // instead of ""
 }


That is just an awful workaround for the lack of default 
constructors.



 May 23 2013



  parent  "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Thu, 23 May 2013 12:09:26 -0400, Don <turnyourkidsintocash nospam.com>  
wrote:


 On Thursday, 23 May 2013 at 13:52:49 UTC, Steven Schveighoffer wrote:

 On Thu, 23 May 2013 05:05:01 -0400, Don  
 <turnyourkidsintocash nospam.com> wrote:


 On Tuesday, 21 May 2013 at 20:36:20 UTC, Walter Bright wrote:

 Join the dmd beta mailing list to keep up with the betas. This one is  
 pretty much good to go, unless something disastrous crops up.

 http://ftp.digitalmars.com/dmd2beta.zip

 Remaining regressions:

 http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED


 NO NO NO NO. I am violently opposed to this release.

 This beta contains the worst language misfeature of all time. It's  
 silently snuck in under the guise of a bugfix.


 struct S
 {
     const int x = 7;
     int y;
 }

 In previous releases, S.x was always 7.
 But now, if you write

 S s = S(5);

 then x gets changed to 5.
 This means that the const variable x has been initialized TWICE!



 This new behaviour is counter-intuitive and introduces a horrible  
 inconsistency.


 I disagree.

 struct S
 {
      const int x;
 }

 S s1; // x is 0



 Of course! It's an uninitialized variable! Try making x a float, and  
 you'll get NaN.


No, it's initialized to NaN.  If it was truly uninitialized, then it would  
be garbage, like C.

In other words, *something* writes NaN into that memory location (or 0, or  
whatever).  The initializer simply dictates what to write.


 S s2 = S(5); // x is 5


 ---

 I can see uses.  If you don't want x.init to be the default for x, then  
 you need to set it to something else.

 For example:

 struct Widget
 {
    immutable string name = "(unset)"; // instead of ""
 }


 That is just an awful workaround for the lack of default constructors.


Why?  The compiler blits a bit-pattern onto the struct before  
initialization.  Why should we not be given the ability to control that  
bit pattern?  It's just data!

I find the argument against this quite puzzling, we should have as much  
power as possible over how the compiler treats our custom types.  I think  
your arguments simply stem from the fact that you did not specify static  
for your static variables, and the compiler loosely accepted that until  
now.

-Steve



 May 23 2013



prev sibling next sibling parent  Manu <turkeyman gmail.com>  writes:


On 23 May 2013 19:05, Don <turnyourkidsintocash nospam.com> wrote:


 On Tuesday, 21 May 2013 at 20:36:20 UTC, Walter Bright wrote:


 Join the dmd beta mailing list to keep up with the betas. This one is
 pretty much good to go, unless something disastrous crops up.

 http://ftp.digitalmars.com/**dmd2beta.zip<http://ftp.digitalmars.com/dmd2beta.zip>

 Remaining regressions:

 http://d.puremagic.com/issues/**buglist.cgi?query_format=**
 advanced&bug_severity=**regression&bug_status=NEW&bug_**
 status=ASSIGNED&bug_status=**REOPENED<http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED>


 NO NO NO NO. I am violently opposed to this release.

 This beta contains the worst language misfeature of all time. It's
 silently snuck in under the guise of a bugfix.


Side note, it's so funny how I can clearly hear everybody's voice and
inflections when reading the NG now!
This post in particular :)

struct S

 {
     const int x = 7;
     int y;
 }

 In previous releases, S.x was always 7.
 But now, if you write

 S s = S(5);

 then x gets changed to 5.
 This means that the const variable x has been initialized TWICE!

 This new behaviour is counter-intuitive and introduces a horrible
 inconsistency.

 This is totally different to what happens with module constructors (you
 get a compile error if you try to set a const global if it already has an
 initializer). Likewise, everywhere else in the language, when you see a
 const variable with an initializer, the initializer gives its value.


 I think the only possible solution is to make it an error to provide a
 const or immutable member with an initializer.

 If you are providing an initializer, you surely meant to make it 'static
 const', and that is certainly true of all existing usages of it.

 As far as I can tell, this new feature exists only to create bugs. No use
 cases for it have been given. I cannot imagine a case where using this
 feature would not be a bug.


 Please do not release this beta.





 May 23 2013



prev sibling  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 5/23/2013 2:05 AM, Don wrote:

 NO NO NO NO. I am violently opposed to this release.

 This beta contains the worst language misfeature of all time. It's silently
 snuck in under the guise of a bugfix.


Don has an excellent point. His case is bolstered by this causing Tango2 to
fail 
to compile with error messages that have no obvious relationship with this
change.

Worse, as Don points out, this can result in silent breakage. Not everyone 
writes code that is 100% tested, and shipping code that no longer works would 
make someone justifiably very upset.

The -transition=field detects such cases, but the user will not necessarily
know 
to run it.

So, I agree with Don. As it is, this is unacceptable, despite my agreement that 
it does make the language better. Therefore, I propose the following addition
of 
a warning:

------------------------------
    const int q = 5;

Warning: const field with initializer should be static or enum.
------------------------------

Over time, this can be upgraded to a deprecation and then an error.

After a suitably long period of time as an error, then we can allow it with the 
new behavior.



 May 23 2013



 next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Thu, 23 May 2013 20:01:19 -0400, Walter Bright  
<newshound2 digitalmars.com> wrote:


 On 5/23/2013 2:05 AM, Don wrote:

 NO NO NO NO. I am violently opposed to this release.

 This beta contains the worst language misfeature of all time. It's  
 silently
 snuck in under the guise of a bugfix.


 Don has an excellent point. His case is bolstered by this causing Tango2  
 to fail to compile with error messages that have no obvious relationship  
 with this change.

 Worse, as Don points out, this can result in silent breakage. Not  
 everyone writes code that is 100% tested, and shipping code that no  
 longer works would make someone justifiably very upset.

 The -transition=field detects such cases, but the user will not  
 necessarily know to run it.


What about making it an error UNLESS you pass a compiler flag.  The user  
will be informed, and the new behavior (which I find useful) is possible.

-Steve



 May 23 2013



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 5/23/2013 5:35 PM, Steven Schveighoffer wrote:

 What about making it an error UNLESS you pass a compiler flag.  The user will
be
 informed, and the new behavior (which I find useful) is possible.


While that idea has significant merit, I oppose it on the following grounds:

1. It forces a very abrupt change. We've followed a policy of gradual change, 
giving people plenty of time to adapt their codebase. This does not.

2. Having optional errors like that leads to unfortunate problems inside
generic 
code that tests whether some constructs compile or not.



 May 23 2013



 next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 5/23/13 8:56 PM, Walter Bright wrote:

 On 5/23/2013 5:35 PM, Steven Schveighoffer wrote:

 What about making it an error UNLESS you pass a compiler flag. The
 user will be
 informed, and the new behavior (which I find useful) is possible.


 While that idea has significant merit, I oppose it on the following
 grounds:

 1. It forces a very abrupt change. We've followed a policy of gradual
 change, giving people plenty of time to adapt their codebase. This does
 not.


I don't understand this. It's change under 100% user control.


 2. Having optional errors like that leads to unfortunate problems inside
 generic code that tests whether some constructs compile or not.


The warning has the same problem.

I'm not seeing a comparison between the warning and the opt-in, but 
instead weak arguments against the opt-in and no comparison with the 
warning.


Andrei



 May 23 2013



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 5/23/2013 6:01 PM, Andrei Alexandrescu wrote:

 On 5/23/13 8:56 PM, Walter Bright wrote:

 On 5/23/2013 5:35 PM, Steven Schveighoffer wrote:

 What about making it an error UNLESS you pass a compiler flag. The
 user will be
 informed, and the new behavior (which I find useful) is possible.


 While that idea has significant merit, I oppose it on the following
 grounds:

 1. It forces a very abrupt change. We've followed a policy of gradual
 change, giving people plenty of time to adapt their codebase. This does
 not.


 I don't understand this. It's change under 100% user control.


Under neither position of the switch is the old runtime behavior maintained.
And 
as I mentioned in another post, the naive (or tired or in a hurry) user just 
throwing the switch to get his code to compile runs the risk of silent breakage 
of the runtime behavior.

Furthermore, when we rename a Phobos function, we don't just delete the old 
name. We go through a period of warnings and deprecations.

I don't believe this change is so needed to justify such an abrupt change. It's 
a minor improvement.



 2. Having optional errors like that leads to unfortunate problems inside
 generic code that tests whether some constructs compile or not.


 The warning has the same problem.


I don't agree that because we have this problem elsewhere, that it should be 
acceptable to add in more cases.



 May 23 2013



prev sibling  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 5/23/2013 5:56 PM, Walter Bright wrote:

 On 5/23/2013 5:35 PM, Steven Schveighoffer wrote:

 What about making it an error UNLESS you pass a compiler flag.  The user will
be
 informed, and the new behavior (which I find useful) is possible.


 While that idea has significant merit, I oppose it on the following grounds:

 1. It forces a very abrupt change. We've followed a policy of gradual change,
 giving people plenty of time to adapt their codebase. This does not.

 2. Having optional errors like that leads to unfortunate problems inside
generic
 code that tests whether some constructs compile or not.


3. Naive users may see their compile fail, see a switch to 'enable' it, and 
throw the switch. Now it compiles, but fails silently at runtime. This is 
because the new behavior is quite different from the old, and the code that 
relies on the old behavior will most likely need to be redone, not just add a 
switch.



 May 23 2013



 next sibling parent reply "bearophile" <bearophileHUGS lycos.com>  writes:


Walter Bright:


 3. Naive users may see their compile fail, see a switch to 
 'enable' it, and throw the switch. Now it compiles, but fails 
 silently at runtime. This is because the new behavior is quite 
 different from the old, and the code that relies on the old 
 behavior will most likely need to be redone, not just add a 
 switch.


Even if such "naive" D programmers exist, maybe it's better to 
ignore this third point, because they will not be able to program 
in D for other reasons.

Bye,
bearophile



 May 23 2013



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 5/23/2013 7:35 PM, bearophile wrote:

 Walter Bright:


 3. Naive users may see their compile fail, see a switch to 'enable' it, and
 throw the switch. Now it compiles, but fails silently at runtime. This is
 because the new behavior is quite different from the old, and the code that
 relies on the old behavior will most likely need to be redone, not just add a
 switch.


 Even if such "naive" D programmers exist, maybe it's better to ignore this
third
 point, because they will not be able to program in D for other reasons.


s/naive/tired/
s/naive/inahurry/

I'm surprised at you, bearophile!



 May 23 2013



 next sibling parent reply "bearophile" <bearophileHUGS lycos.com>  writes:


Walter Bright:


 Even if such "naive" D programmers exist, maybe it's better to 
 ignore this third
 point, because they will not be able to program in D for other 
 reasons.


 s/naive/tired/
 s/naive/inahurry/

 I'm surprised at you, bearophile!


A safe and well designed language is not supposed to save you 
from using on purpose a switch designed to avoid you some bugs. 
So I don't agree with this third point of yours.

Bye,
bearophile



 May 23 2013



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 5/23/2013 7:57 PM, bearophile wrote:

 Walter Bright:


 Even if such "naive" D programmers exist, maybe it's better to ignore this
third
 point, because they will not be able to program in D for other reasons.


 s/naive/tired/
 s/naive/inahurry/

 I'm surprised at you, bearophile!


 A safe and well designed language is not supposed to save you from using on
 purpose a switch designed to avoid you some bugs. So I don't agree with this
 third point of yours.


I think that is inconsistent with your consistent position that features that 
are easily misunderstood or misused should have more protection.

So there!



 May 23 2013



prev sibling  parent  "deadalnix" <deadalnix gmail.com>  writes:


On Friday, 24 May 2013 at 02:39:26 UTC, Walter Bright wrote:

 On 5/23/2013 7:35 PM, bearophile wrote:

 Walter Bright:


 3. Naive users may see their compile fail, see a switch to 
 'enable' it, and
 throw the switch. Now it compiles, but fails silently at 
 runtime. This is
 because the new behavior is quite different from the old, and 
 the code that
 relies on the old behavior will most likely need to be 
 redone, not just add a
 switch.


 Even if such "naive" D programmers exist, maybe it's better to 
 ignore this third
 point, because they will not be able to program in D for other 
 reasons.


 s/naive/tired/
 s/naive/inahurry/

 I'm surprised at you, bearophile!


I have to second Walter on that one. This does and probably will 
happen, even with programmer that aren't brain damaged.



 May 23 2013



prev sibling  parent reply "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Thu, 23 May 2013 21:56:47 -0400, Walter Bright  
<newshound2 digitalmars.com> wrote:


 On 5/23/2013 5:56 PM, Walter Bright wrote:

 On 5/23/2013 5:35 PM, Steven Schveighoffer wrote:

 What about making it an error UNLESS you pass a compiler flag.  The  
 user will be
 informed, and the new behavior (which I find useful) is possible.


 While that idea has significant merit, I oppose it on the following  
 grounds:

 1. It forces a very abrupt change. We've followed a policy of gradual  
 change,
 giving people plenty of time to adapt their codebase. This does not.




What we need is a message that says "what you are doing is wrong, you need  
to put static in front of it."  Since the new behavior never before  
existed, all existing code will be identical if they put static before the  
declaration.

There is no real time needed to adapt their codebase, except for the time  
it takes to find the errors, open a file, type "static " and save it.  No  
thinking is involved.  The error message can say as much.


 2. Having optional errors like that leads to unfortunate problems  
 inside generic
 code that tests whether some constructs compile or not.




I just realized that there is a large problem with my proposed solution.   
Let's say one library writer has not updated his code to work with the  
latest compiler.  Another library writer starts using the new feature.

Compile them together, and now you have a mish-mash of valid and invalid  
code that either all fails or all compiles based on a switch.

I think the only good solution is to use an error.  A warning is not good  
enough/strong enough.  This is one change where ALL code broken by this  
change is fixable with a simple solution, and at some point, people will  
have to deal with this.


 3. Naive users may see their compile fail, see a switch to 'enable' it,  
 and throw the switch. Now it compiles, but fails silently at runtime.  
 This is because the new behavior is quite different from the old, and  
 the code that relies on the old behavior will most likely need to be  
 redone, not just add a switch.


Naive users may do a lot of things to "get it to work."  They may remove  
the const.  I don't think we can guard against naivety.

-Steve



 May 23 2013



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 5/23/2013 7:38 PM, Steven Schveighoffer wrote:

 On Thu, 23 May 2013 21:56:47 -0400, Walter Bright <newshound2 digitalmars.com>
 wrote:


 On 5/23/2013 5:56 PM, Walter Bright wrote:

 On 5/23/2013 5:35 PM, Steven Schveighoffer wrote:

 What about making it an error UNLESS you pass a compiler flag.  The user
 will be
 informed, and the new behavior (which I find useful) is possible.


 While that idea has significant merit, I oppose it on the following grounds:

 1. It forces a very abrupt change. We've followed a policy of gradual change,
 giving people plenty of time to adapt their codebase. This does not.




 What we need is a message that says "what you are doing is wrong, you need to
 put static in front of it."  Since the new behavior never before existed, all
 existing code will be identical if they put static before the declaration.

 There is no real time needed to adapt their codebase, except for the time it
 takes to find the errors, open a file, type "static " and save it.  No thinking
 is involved.  The error message can say as much.


 2. Having optional errors like that leads to unfortunate problems inside
generic
 code that tests whether some constructs compile or not.




 I just realized that there is a large problem with my proposed solution.  Let's
 say one library writer has not updated his code to work with the latest
 compiler.  Another library writer starts using the new feature.

 Compile them together, and now you have a mish-mash of valid and invalid code
 that either all fails or all compiles based on a switch.


Yeah, that is a problem I hadn't thought of.


 I think the only good solution is to use an error.


Yes, and the error has to be there for long enough to get all the existing code 
in use to be corrected before the new behavior is enabled.


 A warning is not good
 enough/strong enough.


For now, it is the proper path. The warning is that "change is coming, but you 
have time to fix it."


 This is one change where ALL code broken by this change
 is fixable with a simple solution, and at some point, people will have to deal
 with this.


Yes, but it is not so urgent as RIGHT NOW YOU MUST FIX IT. Hence, the warning.



 May 23 2013



 next sibling parent  "deadalnix" <deadalnix gmail.com>  writes:


On Friday, 24 May 2013 at 03:38:33 UTC, Walter Bright wrote:

 For now, it is the proper path. The warning is that "change is 
 coming, but you have time to fix it."


Yes, with an explanation how to fix it, maybe a link to a webpage 
that explain why the change is made, etc . . .



 May 23 2013



prev sibling  parent reply "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Thu, 23 May 2013 23:38:32 -0400, Walter Bright  
<newshound2 digitalmars.com> wrote:


 On 5/23/2013 7:38 PM, Steven Schveighoffer wrote:

 This is one change where ALL code broken by this change
 is fixable with a simple solution, and at some point, people will have  
 to deal
 with this.


 Yes, but it is not so urgent as RIGHT NOW YOU MUST FIX IT. Hence, the  
 warning.


If they aren't in the mood to change their code, they don't have to  
upgrade to the latest compiler.

-Steve



 May 23 2013



 next sibling parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 5/23/2013 8:53 PM, Steven Schveighoffer wrote:

 On Thu, 23 May 2013 23:38:32 -0400, Walter Bright <newshound2 digitalmars.com>
 wrote:


 On 5/23/2013 7:38 PM, Steven Schveighoffer wrote:

 This is one change where ALL code broken by this change
 is fixable with a simple solution, and at some point, people will have to deal
 with this.


 Yes, but it is not so urgent as RIGHT NOW YOU MUST FIX IT. Hence, the warning.


 If they aren't in the mood to change their code, they don't have to upgrade to
 the latest compiler.


Q: Why do we bother with the whole warning and deprecation thing anyway?

A: Because forcing people to conform to our schedule with no warning is a bit 
presumptuous. Someone writing a library, for example, has to be up to date, and 
anyone using that library, for another, has to deal with it if it fails to 
compile. If your code is built from multiple blobs from various places, it is 
unreasonable to expect them to all instantly and simultaneously upgrade.


I'm a little startled by these responses, especially considering that just 
yesterday we had a long thread about lack of stability and breaking changes.



 May 23 2013



  parent  Sean Cavanaugh <WorksOnMyMachine gmail.com>  writes:


On 5/23/2013 11:17 PM, Walter Bright wrote:

 On 5/23/2013 8:53 PM, Steven Schveighoffer wrote:

 On Thu, 23 May 2013 23:38:32 -0400, Walter Bright
 <newshound2 digitalmars.com>
 wrote:


 On 5/23/2013 7:38 PM, Steven Schveighoffer wrote:

 This is one change where ALL code broken by this change
 is fixable with a simple solution, and at some point, people will
 have to deal
 with this.


 Yes, but it is not so urgent as RIGHT NOW YOU MUST FIX IT. Hence, the
 warning.


 If they aren't in the mood to change their code, they don't have to
 upgrade to
 the latest compiler.


 Q: Why do we bother with the whole warning and deprecation thing anyway?

 A: Because forcing people to conform to our schedule with no warning is
 a bit presumptuous. Someone writing a library, for example, has to be up
 to date, and anyone using that library, for another, has to deal with it
 if it fails to compile. If your code is built from multiple blobs from
 various places, it is unreasonable to expect them to all instantly and
 simultaneously upgrade.


I would argue the language should be designed with the ability to easily 
add keywords without breaking things.  I would expect a simple 
implementation to be that each source file needs to be marked up with a 
version of the compiler it is designed for, and the compiler could tell 
you that A) you are using what is now a keywords B) compile the code 
correctly anyway.

The lack of this kind of feature is why c++11's new null type is named 
nullptr, and not null, and why pure virtuals are declared with '=0' 
instead of a keyword.  Arguably c++11's range based for loops are also 
designed with this constraint (avoid adding a keyword), but is a not 
ugly like =0 pure virtuals :)



 May 23 2013



prev sibling  parent reply Leandro Lucarella <luca llucax.com.ar>  writes:


Steven Schveighoffer, el 23 de May a las 23:53 me escribiste:

 On Thu, 23 May 2013 23:38:32 -0400, Walter Bright
 <newshound2 digitalmars.com> wrote:
 

On 5/23/2013 7:38 PM, Steven Schveighoffer wrote:

This is one change where ALL code broken by this change
is fixable with a simple solution, and at some point, people
will have to deal
with this.


Yes, but it is not so urgent as RIGHT NOW YOU MUST FIX IT. Hence,
the warning.


 
 If they aren't in the mood to change their code, they don't have to
 upgrade to the latest compiler.


That's completely FALSE. You might need some bugfixes! That view of "if
you want to be up to date you have to be willing to update a lot of
code" is really hurting D's stability.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Hola soy Angie. Quería preguntarles como inserto un archivo .cab (paquete
hecho en Visual Basic contiene una librería y un ocx) en Internet Explorer
para después me deje trabajar en PHP con este .cab



 May 27 2013



  parent  "F i L" <witte2008 gmail.com>  writes:


Leandro Lucarella wrote:

 That's completely FALSE. You might need some bugfixes! That 
 view of "if you want to be up to date you have to be
 willing to update a lot of code" is really hurting D's
 stability.


Evolution was never pain-free. The idea that D can thrive without 
adapting to it's changing environment will really hurt D's 
popularity now and in the future.

Isn't the feature you folks are talking about technically a 
bug-fix? IMO it's better to use an older compiler if you really 
need your work-arounds to function (granted there is proper 
docs), and let the rest of people adapt with the language.



 May 28 2013



prev sibling next sibling parent  "bearophile" <bearophileHUGS lycos.com>  writes:


Walter Bright:


 Therefore, I propose the following addition of a warning:

 ------------------------------
    const int q = 5;

 Warning: const field with initializer should be static or enum.
 ------------------------------
 Over time, this can be upgraded to a deprecation and then an 
 error.

 After a suitably long period of time as an error, then we can 
 allow it with the new behavior.


Given the current rate of DMD releases this change path will take 
a good amount of time.

In the next weeks I suggest to write down the most complete as 
possible list of desired or expected breaking language changes, 
and start performing them as early as possible (like during the 
development of dmd 2.064).

Packing all (or most) of such changes in parallel (instead one 
after the other along successive compiler versions, as it's 
mostly currently done) will reduce code breakages later or much 
later. Bugzilla contains several of such issues (often they are 
enhancement requests). If we fix only 3-5 every year, D will take 
many more years to ""stabilize"".

----------------------

Steven Schveighoffer:


 What about making it an error UNLESS you pass a compiler flag.  
 The user  will be informed, and the new behavior (which I find 
 useful) is possible.


This idea seems able to significantly speed up the transition.

Bye,
bearophile



 May 23 2013



prev sibling next sibling parent  Jacob Carlborg <doob me.com>  writes:


On 2013-05-24 02:01, Walter Bright wrote:


 Don has an excellent point. His case is bolstered by this causing Tango2
 to fail to compile with error messages that have no obvious relationship
 with this change.

 Worse, as Don points out, this can result in silent breakage. Not
 everyone writes code that is 100% tested, and shipping code that no
 longer works would make someone justifiably very upset.

 The -transition=field detects such cases, but the user will not
 necessarily know to run it.

 So, I agree with Don. As it is, this is unacceptable, despite my
 agreement that it does make the language better. Therefore, I propose
 the following addition of a warning:

 ------------------------------
     const int q = 5;

 Warning: const field with initializer should be static or enum.
 ------------------------------

 Over time, this can be upgraded to a deprecation and then an error.

 After a suitably long period of time as an error, then we can allow it
 with the new behavior.


I like that idea. It doesn't suddenly breaking existing code. Gives a 
bit of transition time.

-- 
/Jacob Carlborg



 May 23 2013



prev sibling next sibling parent  "Dicebot" <m.strashun gmail.com>  writes:


I like it. A lot, probably.

When semantics of something does change it makes a lot sense to 
decouple deprecation of old behavior and introduction of new. I 
may even say it is worth using as a default approach for a 
semantics change in similar cases ;)

On Friday, 24 May 2013 at 00:01:20 UTC, Walter Bright wrote:

 On 5/23/2013 2:05 AM, Don wrote:

 NO NO NO NO. I am violently opposed to this release.

 This beta contains the worst language misfeature of all time. 
 It's silently
 snuck in under the guise of a bugfix.


 Don has an excellent point. His case is bolstered by this 
 causing Tango2 to fail to compile with error messages that have 
 no obvious relationship with this change.

 Worse, as Don points out, this can result in silent breakage. 
 Not everyone writes code that is 100% tested, and shipping code 
 that no longer works would make someone justifiably very upset.

 The -transition=field detects such cases, but the user will not 
 necessarily know to run it.

 So, I agree with Don. As it is, this is unacceptable, despite 
 my agreement that it does make the language better. Therefore, 
 I propose the following addition of a warning:

 ------------------------------
    const int q = 5;

 Warning: const field with initializer should be static or enum.
 ------------------------------

 Over time, this can be upgraded to a deprecation and then an 
 error.

 After a suitably long period of time as an error, then we can 
 allow it with the new behavior.





 May 24 2013



prev sibling  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


Pull request to do this: https://github.com/D-Programming-Language/dmd/pull/2076

On 5/23/2013 5:01 PM, Walter Bright wrote:

 On 5/23/2013 2:05 AM, Don wrote:

 NO NO NO NO. I am violently opposed to this release.

 This beta contains the worst language misfeature of all time. It's silently
 snuck in under the guise of a bugfix.


 Don has an excellent point. His case is bolstered by this causing Tango2 to
fail
 to compile with error messages that have no obvious relationship with this
change.

 Worse, as Don points out, this can result in silent breakage. Not everyone
 writes code that is 100% tested, and shipping code that no longer works would
 make someone justifiably very upset.

 The -transition=field detects such cases, but the user will not necessarily
know
 to run it.

 So, I agree with Don. As it is, this is unacceptable, despite my agreement that
 it does make the language better. Therefore, I propose the following addition
of
 a warning:

 ------------------------------
     const int q = 5;

 Warning: const field with initializer should be static or enum.
 ------------------------------

 Over time, this can be upgraded to a deprecation and then an error.

 After a suitably long period of time as an error, then we can allow it with the
 new behavior.





 May 25 2013



  parent reply "deadalnix" <deadalnix gmail.com>  writes:


On Saturday, 25 May 2013 at 21:07:26 UTC, Walter Bright wrote:

 Pull request to do this: 
 https://github.com/D-Programming-Language/dmd/pull/2076


So finally, what is the sate of things ?



 May 26 2013



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 5/26/2013 9:31 AM, deadalnix wrote:

 On Saturday, 25 May 2013 at 21:07:26 UTC, Walter Bright wrote:

 Pull request to do this:
https://github.com/D-Programming-Language/dmd/pull/2076


 So finally, what is the sate of things ?


Beta 7!


http://ftp.digitalmars.com/dmd2beta.zip

Remaining regressions:

http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED



 May 26 2013



  parent reply "deadalnix" <deadalnix gmail.com>  writes:


On Sunday, 26 May 2013 at 18:52:11 UTC, Walter Bright wrote:

 On 5/26/2013 9:31 AM, deadalnix wrote:

 On Saturday, 25 May 2013 at 21:07:26 UTC, Walter Bright wrote:

 Pull request to do this: 
 https://github.com/D-Programming-Language/dmd/pull/2076


 So finally, what is the sate of things ?


 Beta 7!


 http://ftp.digitalmars.com/dmd2beta.zip

 Remaining regressions:

 http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED


Sorry I was unclear. The question was about the chosen behavior 
for immutable/const initialization.



 May 26 2013



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 5/26/2013 8:05 PM, deadalnix wrote:

 On Sunday, 26 May 2013 at 18:52:11 UTC, Walter Bright wrote:

 On 5/26/2013 9:31 AM, deadalnix wrote:

 On Saturday, 25 May 2013 at 21:07:26 UTC, Walter Bright wrote:

 Pull request to do this:
 https://github.com/D-Programming-Language/dmd/pull/2076


 So finally, what is the sate of things ?


 Beta 7!


 http://ftp.digitalmars.com/dmd2beta.zip

 Remaining regressions:

 http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED


 Sorry I was unclear. The question was about the chosen behavior for
 immutable/const initialization.


I think the pull request answers that.



 May 26 2013



prev sibling next sibling parent reply Timothee Cour <thelastmammoth gmail.com>  writes:


just filed a regression from 062 to 063:
http://d.puremagic.com/issues/show_bug.cgi?id=10141
it only affects error message though (giving a nonsensical error message).

Digression:
I used dustmite to reduce it (awesome tool) down to 6 files, but then had
to further manually reduce to 1 file.
I wish dustmite could be improved to 'run the last mile' by attempting to
merge files:
a.d:
import b;
b.d:
import c;
c.d:
//some stuff

dustmite should attempt to merge such files and reduce to:
a.d
// some stuff




On Tue, May 21, 2013 at 1:36 PM, Walter Bright
<newshound2 digitalmars.com>wrote:


 Join the dmd beta mailing list to keep up with the betas. This one is
 pretty much good to go, unless something disastrous crops up.

 http://ftp.digitalmars.com/**dmd2beta.zip<http://ftp.digitalmars.com/dmd2beta.zip>

 Remaining regressions:

 http://d.puremagic.com/issues/**buglist.cgi?query_format=**
 advanced&bug_severity=**regression&bug_status=NEW&bug_**
 status=ASSIGNED&bug_status=**REOPENED<http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED>





 May 23 2013



  parent reply "Vladimir Panteleev" <vladimir thecybershadow.net>  writes:


On Thursday, 23 May 2013 at 09:35:03 UTC, Timothee Cour wrote:

 I wish dustmite could be improved to 'run the last mile' by 
 attempting to
 merge files:
 a.d:
 import b;
 b.d:
 import c;
 c.d:
 //some stuff

 dustmite should attempt to merge such files and reduce to:
 a.d
 // some stuff


Added! 
https://github.com/CyberShadow/DustMite/commit/24ebc57858168c9fe4dea99e859ac6ccadab685c

It's been asked before, I think. It should work for simple cases 
(when the program can compile after all files' contents is moved 
into one single file). The obstacles with making it more flexible 
are that 1) to merge every pair of files, it would have to try 
N*(N-1) combinations; 2) it doesn't know which file is the "main" 
program file (the file which must be present for the test script 
to succeed), if there is one.



 May 23 2013



  parent reply Andrej Mitrovic <andrej.mitrovich gmail.com>  writes:


On 5/23/13, Vladimir Panteleev <vladimir thecybershadow.net> wrote:

 2) it doesn't know which file is the "main"
 program file (the file which must be present for the test script
 to succeed), if there is one.


Does https://github.com/D-Programming-Language/dmd/pull/1732 help? It
was merged a while back.



 May 23 2013



  parent  "Vladimir Panteleev" <vladimir thecybershadow.net>  writes:


On Thursday, 23 May 2013 at 22:25:18 UTC, Andrej Mitrovic wrote:

 On 5/23/13, Vladimir Panteleev <vladimir thecybershadow.net> 
 wrote:

 2) it doesn't know which file is the "main"
 program file (the file which must be present for the test 
 script
 to succeed), if there is one.


 Does https://github.com/D-Programming-Language/dmd/pull/1732 
 help? It
 was merged a while back.


DustMite would need to dissect the user's command line and inject 
the switch. With probably the same amount of success, it'd be 
easier to heuristically detect a filename in the supplied command 
line, but that's something I'd like to avoid. Timothee continued 
the discussion in a DustMite issue: 
https://github.com/CyberShadow/DustMite/issues/13



 May 24 2013



prev sibling next sibling parent reply Iain Buclaw <ibuclaw ubuntu.com>  writes:


On 21 May 2013 21:36, Walter Bright <newshound2 digitalmars.com> wrote:

 Join the dmd beta mailing list to keep up with the betas. This one is pretty
 much good to go, unless something disastrous crops up.

 http://ftp.digitalmars.com/dmd2beta.zip

 Remaining regressions:

 http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED



Is this zip based off the 2.063 branch?    Seems to be cherry picking
the odd commit over the last couple of days....

--
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';



 May 23 2013



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 5/23/2013 4:07 AM, Iain Buclaw wrote:

 On 21 May 2013 21:36, Walter Bright <newshound2 digitalmars.com> wrote:

 Join the dmd beta mailing list to keep up with the betas. This one is pretty
 much good to go, unless something disastrous crops up.

 http://ftp.digitalmars.com/dmd2beta.zip

 Remaining regressions:

 http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED



 Is this zip based off the 2.063 branch?


Yes, that's the whole point!


 Seems to be cherry picking the odd commit over the last couple of days....


It's cherry picking the regression fixes.



 May 23 2013



  parent  Iain Buclaw <ibuclaw ubuntu.com>  writes:


On 23 May 2013 22:46, Walter Bright <newshound2 digitalmars.com> wrote:

 On 5/23/2013 4:07 AM, Iain Buclaw wrote:

 On 21 May 2013 21:36, Walter Bright <newshound2 digitalmars.com> wrote:

 Join the dmd beta mailing list to keep up with the betas. This one is
 pretty
 much good to go, unless something disastrous crops up.

 http://ftp.digitalmars.com/dmd2beta.zip

 Remaining regressions:


 http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED




 Is this zip based off the 2.063 branch?



 Yes, that's the whole point!



 Seems to be cherry picking the odd commit over the last couple of days....



 It's cherry picking the regression fixes.


Not at all a problem, just means I'll be updating to 2.063 + some
extra patches that didn't make it into the release this time around.

--
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';



 May 23 2013



prev sibling next sibling parent reply Timothee Cour <thelastmammoth gmail.com>  writes:


and another regression, this time more serious, that came up in my code:

http://d.puremagic.com/issues/show_bug.cgi?id=10148

Note, dustmite got stuck forever trying to reduce it, so i had to reduce
manually.


On Tue, May 21, 2013 at 1:36 PM, Walter Bright
<newshound2 digitalmars.com>wrote:


 Join the dmd beta mailing list to keep up with the betas. This one is
 pretty much good to go, unless something disastrous crops up.

 http://ftp.digitalmars.com/**dmd2beta.zip<http://ftp.digitalmars.com/dmd2beta.zip>

 Remaining regressions:

 http://d.puremagic.com/issues/**buglist.cgi?query_format=**
 advanced&bug_severity=**regression&bug_status=NEW&bug_**
 status=ASSIGNED&bug_status=**REOPENED<http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED>





 May 23 2013



  parent  "Vladimir Panteleev" <vladimir thecybershadow.net>  writes:


On Thursday, 23 May 2013 at 11:33:53 UTC, Timothee Cour wrote:

 Note, dustmite got stuck forever trying to reduce it, so i had 
 to reduce
 manually.


You may need to use Dustmite together with the "timeout" command 
for cases when the test command may hang indefinitely:

https://github.com/CyberShadow/DustMite/wiki/Running-commands-with-a-timeout



 May 23 2013



prev sibling next sibling parent reply "deadalnix" <deadalnix gmail.com>  writes:


On Tuesday, 21 May 2013 at 20:36:20 UTC, Walter Bright wrote:

 Join the dmd beta mailing list to keep up with the betas. This 
 one is pretty much good to go, unless something disastrous 
 crops up.

 http://ftp.digitalmars.com/dmd2beta.zip

 Remaining regressions:

 http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED


Add that one : http://d.puremagic.com/issues/show_bug.cgi?id=10151

Once again my code is broken. I can understand both behavior, but 
the change don't really make sense. This time the ROI is doubtful.



 May 23 2013



  parent reply "deadalnix" <deadalnix gmail.com>  writes:


On Thursday, 23 May 2013 at 16:44:03 UTC, deadalnix wrote:

 On Tuesday, 21 May 2013 at 20:36:20 UTC, Walter Bright wrote:

 Join the dmd beta mailing list to keep up with the betas. This 
 one is pretty much good to go, unless something disastrous 
 crops up.

 http://ftp.digitalmars.com/dmd2beta.zip

 Remaining regressions:

 http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED


 Add that one : 
 http://d.puremagic.com/issues/show_bug.cgi?id=10151

 Once again my code is broken. I can understand both behavior, 
 but the change don't really make sense. This time the ROI is 
 doubtful.


Solved, but now I fail on :
Error: template std.utf.decodeFront does not match any function 
template declaration. Candidates are:
  ... // Many candidates.



 May 24 2013



  parent  "deadalnix" <deadalnix gmail.com>  writes:


On Friday, 24 May 2013 at 13:06:03 UTC, deadalnix wrote:

 Solved, but now I fail on :
 Error: template std.utf.decodeFront does not match any function 
 template declaration. Candidates are:
  ... // Many candidates.


So I fixed it, now I have another regression (or a new feature) : 
"Foo is not a template" en masse.

dustmiting right now.



 May 24 2013



prev sibling next sibling parent reply "nazriel" <spam dzfl.pl>  writes:


On Tuesday, 21 May 2013 at 20:36:20 UTC, Walter Bright wrote:

 Join the dmd beta mailing list to keep up with the betas. This 
 one is pretty much good to go, unless something disastrous 
 crops up.

 http://ftp.digitalmars.com/dmd2beta.zip


Is it possible to change zip filename from dmd2beta.zip to 
dmd.2beta.zip ?
It would allow tools like DVM fetch it and install automatically 
for us.


 Remaining regressions:

 http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED





 May 23 2013



  parent  Jacob Carlborg <doob me.com>  writes:


On 2013-05-23 20:30, nazriel wrote:


 Is it possible to change zip filename from dmd2beta.zip to dmd.2beta.zip ?
 It would allow tools like DVM fetch it and install automatically for us.


Good point, I have wanted to add support for betas in DVM for a while.

-- 
/Jacob Carlborg



 May 23 2013



prev sibling next sibling parent  "Ellery Newcomer" <ellery-newcomer utulsa.edu>  writes:


On Tuesday, 21 May 2013 at 20:36:20 UTC, Walter Bright wrote:

 Join the dmd beta mailing list to keep up with the betas. This 
 one is pretty much good to go, unless something disastrous 
 crops up.

 http://ftp.digitalmars.com/dmd2beta.zip

 Remaining regressions:

 http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED


<repost in case the ether ate the last one>

just tried building a shared lib with

dmd -fPIC -defaultlib=phobos2so -shared {infiles} -of{outfile}

on ubuntu 12.10 64bit.

during link, it wants libphobos2so.so, but during run it wants 
libphobos2.so.0.63



 May 24 2013



prev sibling  parent  "deadalnix" <deadalnix gmail.com>  writes:


On Tuesday, 21 May 2013 at 20:36:20 UTC, Walter Bright wrote:

 Join the dmd beta mailing list to keep up with the betas. This 
 one is pretty much good to go, unless something disastrous 
 crops up.

 http://ftp.digitalmars.com/dmd2beta.zip

 Remaining regressions:

 http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED


You can add that one :
http://d.puremagic.com/issues/show_bug.cgi?id=10166



 May 25 2013