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';

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

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.

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

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.

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

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

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

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';

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));
}