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

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

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

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

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

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

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.

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

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

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.