http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.037.zip



http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.021.zip

Make that 2.021, not 2.020

On Tue, 25 Nov 2008 14:22:47 -0800, Walter Bright wrote:

> http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.037.zip
> 
> http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.021.zip

It would appear that Bugzilla 313 () is not really fixed yet.

// --- file: sub.d ---
module sub;
private int iPrivate = 12;

public  int iPublic = 13;
---------------------------------


// --- file: test.d ---

import sub;
void main()
{
        int i;
        int j;

        i = sub.iPrivate;

        j = sub.iPublic;
}
--------------------

C:>dmd test sub

RESULTS: Successfully compiled
  ** which is not what I expected as sub.iPrivate is private.

// --- file: test1.d ---

import sub;
void main()
{
        int i;
        int j;

        i = iPrivate;

        j = iPublic;
}
--------------------

C:>dmd test1 sub
RESULTS: test1.d: module test1 sub.iPrivate is private
  ** which is as I expected.


-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell

Walter Bright wrote:
> 
> http://www.digitalmars.com/d/1.0/changelog.html
> http://ftp.digitalmars.com/dmd.1.037.zip
> 
> 
> 
> http://www.digitalmars.com/d/2.0/changelog.html
> http://ftp.digitalmars.com/dmd.2.021.zip
> 

929 & 2326 fixed in D1... scope in D2... good times... Thanks Walter, Sean & everyone else involved!

== Quote from Robert Fraser (fraserofthenight@gmail.com)'s article
> Walter Bright wrote:
> >
> > http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.037.zip
> >
> > http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.021.zip
> >
> 929 & 2326 fixed in D1... scope in D2... good times... Thanks Walter, Sean & everyone else involved!

Can I just say how weird it is to not have to rush and merge changes after a DMD release? :-)


Sean

1.037 compiles my dlibs fine :-) And with no other increase of exe size.

Thank you for fixing 929, ASAP I'll remove about 100-150 lines of code from my dlibs :-) Also thank you for 1797, a little problem, but nice to have it fixed.

I am sad reading Derek Parnell say that 313 isn't fixed yet.

From D2:
- What is module(system) Identifier; syntax?
- Added range support to foreach statement. What is this?
- >The 'this' parameter to struct member functions is now a reference type,< I know this was discussed, but how does this change code? Does this forces to change C code when it is ported to D? How to do such porting? Few examples of situations may be useful.

Bye and thank you,
bearophile

== Quote from bearophile (bearophileHUGS@lycos.com)'s article
> 1.037 compiles my dlibs fine :-) And with no other increase of exe size.
> Thank you for fixing 929, ASAP I'll remove about 100-150 lines of code from my dlibs :-)
> Also thank you for 1797, a little problem, but nice to have it fixed.
> I am sad reading Derek Parnell say that 313 isn't fixed yet.
> From D2:
> - What is module(system) Identifier; syntax?

I think this is to tell the compiler that the module is a "system" module and therefore should be exempt from "Safe D" checking.

> - >The 'this' parameter to struct member functions is now a reference type,< I know this was
discussed, but how does this change code? Does this forces to change C code when it is ported to D? How to do such porting? Few examples of situations may be useful.

I think it only affects structs:

struct S
{
    S fn()
    {
        return *this; // old D 2.0
        return this; // new D 2.0
    }
}


Sean

On Wed, Nov 26, 2008 at 7:40 AM, Derek Parnell <derek@psych.ward> wrote:
> On Tue, 25 Nov 2008 14:22:47 -0800, Walter Bright wrote:
>
>> http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.037.zip
>>
>> http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.021.zip
>
> It would appear that Bugzilla 313 () is not really fixed yet.
>
> // --- file: sub.d ---
> module sub;
> private int iPrivate = 12;
>
> public  int iPublic = 13;
> ---------------------------------
>

Maybe the problem is just with package-less top-level modules?

Because the change definitely created lots of errors in my code about things I was using that I didn't know were private.

For one, I was using std.conv.toString in a lot of places without realizing that toString was not actually publicly aliased by std.conv.

I really think it should accessible via std.conv.  Why should I have to import std.string to go from some type-->string, vs std.conv when I want to go string-->type?

--bb

On Wed, 26 Nov 2008 10:51:49 +0900, Bill Baxter wrote:

> On Wed, Nov 26, 2008 at 7:40 AM, Derek Parnell <derek@psych.ward> wrote:
>> On Tue, 25 Nov 2008 14:22:47 -0800, Walter Bright wrote:
>>
>>> http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.037.zip
>>>
>>> http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.021.zip
>>
>> It would appear that Bugzilla 313 () is not really fixed yet.
>>
>> // --- file: sub.d ---
>> module sub;
>> private int iPrivate = 12;
>>
>> public  int iPublic = 13;
>> ---------------------------------
>>
> 
> Maybe the problem is just with package-less top-level modules?

Just tested that too, and it still fails to do what I expected it to do.

// --- file: foo/sub.d
module foo.sub;
private int iPrivate = 12;

public  int iPublic = 13;

package int iPackage = 14; //------------------------------//

// --- file: test.d
module test;
import foo.sub;
void main()
{
        int i;
        int j;
        int k;

        i = foo.sub.iPrivate;
        j = foo.sub.iPublic;
        k = foo.sub.iPackage;
}
//------------------------------//

// --- file: test1.d
module test;
import foo.sub;
void main()
{
        int i;
        int j;
        int k;

        i = iPrivate;
        j = iPublic;
        k = iPackage;
}
//------------------------------//



C:\temp>dmd test foo/sub

C:\temp>dmd test1 foo/sub
test1.d: module test foo.sub.iPrivate is private

C:\temp>dmd
Digital Mars D Compiler v2.021
Copyright (c) 1999-2008 by Digital Mars written by Walter Bright
Documentation: http://www.digitalmars.com/d/2.0/index.html



-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell

On Tue, 25 Nov 2008 14:22:47 -0800, Walter Bright wrote:

> http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.037.zip
> 
> http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.021.zip

An update to the Bugzilla 313 issue...

It appears that it is fixed only with respect to accessing routines but not fixed when accessing variables.

// --- file: foo/sub.d
module foo.sub;
private
{
        int iPrivate = 12;
        int rPrivate() { return 12; }
}

public
{
        int iPublic = 13;
        int rPublic() { return 13; }
}

package
{
        int iPackage = 14;
        int rPackage() { return 14; }
}
//------------------------------//


// --- file: test.d
module test;
import foo.sub;
void main()
{
        int i;
        int j;
        int k;

        i = foo.sub.iPrivate;
        j = foo.sub.iPublic;
        k = foo.sub.iPackage;
        i = foo.sub.rPrivate();
        j = foo.sub.rPublic();
        k = foo.sub.rPackage();
}
//------------------------------//

// --- file: test1.d
module test;
import foo.sub;
void main()
{
        int i;
        int j;
        int k;

        i = iPrivate;
        j = iPublic;
        k = iPackage;
        i = rPrivate();
        j = rPublic();
        k = rPackage();
}
//------------------------------//

C:\temp>dmd test foo/sub
test.d(13): Error: function sub.rPrivate is not accessible from test
test.d(15): Error: function sub.rPackage is not accessible from test

C:\temp>dmd test1 foo/sub
test1.d: module test foo.sub.iPrivate is private
test1.d: module test foo.sub.rPrivate is private
test1.d(13): Error: function sub.rPrivate is not accessible from test
test1.d(15): Error: function sub.rPackage is not accessible from test

C:\temp>dmd
Digital Mars D Compiler v1.037
Copyright (c) 1999-2008 by Digital Mars written by Walter Bright
Documentation: http://www.digitalmars.com/d/1.0/index.html

In my opinion, both test.d and test1.d should be issuing the same error messages, and the messages from test1.d (without full name qualifications) seem to be correct.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell