2013/11/10 Daniel Murphy <yebblies@nospamgmail.com>

> "Kenji Hara" <k.hara.pg@gmail.com> wrote in message news:mailman.336.1384083327.9546.digitalmars-d@puremagic.com...
> >
> > This is valid. Because not only strongly pure function will return unique object.
> >
> > For example:
> >  immutable(int)[] foo(int[] iarr) pure { ... }
> >  int[] marr = foo([1,2,3]);
> >  // foo will never return the arr argument (without unsafe cast).
> >
>
> This one is incorrect, the value returned from foo could be an immutable global.  The unique conversion is only capable of changing non-mutable to immutable, not the other way around.
>

foo is pure, so it cannot return "immutable global".

Maybe you meant something like this?
>
> int[] foo(const(int)[] iarr) pure { ... }
>

Of course, both your case and mine are valid.

Kenji Hara

2013/11/10 Daniel Davidson <nospam@spam.com>

> On Sunday, 10 November 2013 at 06:46:47 UTC, Kenji Hara wrote:
>
>> http://wiki.dlang.org/DIP49
>>
>> Experimental compiler/druntime patches (WIP, 80% completed): https://github.com/9rnsr/dmd/tree/qual_pblit https://github.com/9rnsr/druntime/tree/qual_pblit
>>
>> Kenji Hara
>>
>
> Does the analysis hold up the same if the type held in the array itself has mutable aliasing?
>
> struct T { int[] i; }
> struct S { T[] t; }
>
> Also, does it hold up with associative arrays?
>
> struct S { string[string] aa; }
>

Yes.


> With this design, is there no need then for struct constructors - or would this be orthogonal or in addition to those?
>


Currently "constructing unique object" is already supported.

http://dlang.org/class#constructors
> If the constructor can create unique object (e.g. if it is pure), the
object can be implicitly convertible to any qualifiers.

Indeed, the definition could be improved by using "initializing unique expression" concept. But it is not directly related to the DIP49. So the answer is "this is orthogonal".

Kenji Hara

"Kenji Hara" <k.hara.pg@gmail.com> wrote in message news:mailman.339.1384090714.9546.digitalmars-d@puremagic.com...
> 2013/11/10 Daniel Murphy <yebblies@nospamgmail.com>
>
>> "Kenji Hara" <k.hara.pg@gmail.com> wrote in message news:mailman.336.1384083327.9546.digitalmars-d@puremagic.com...
>> >
>> > This is valid. Because not only strongly pure function will return
>> > unique
>> > object.
>> >
>> > For example:
>> >  immutable(int)[] foo(int[] iarr) pure { ... }
>> >  int[] marr = foo([1,2,3]);
>> >  // foo will never return the arr argument (without unsafe cast).
>> >
>>
>> This one is incorrect, the value returned from foo could be an immutable global.  The unique conversion is only capable of changing non-mutable to immutable, not the other way around.
>>
>
> foo is pure, so it cannot return "immutable global".
>

Pure functions _can_ read immutable global variables.

immutable x = [1, 2, 3];

void main() pure
{
    assert(x[1] == 2);
}

Even if they couldn't, the immutable -> mutable conversion would still not be safe.

edit: uh-oh this actually compiles.  Did you do this?

eg

import std.stdio;

struct S
{
    immutable(S)* s;
    this(int) immutable pure
    {
        s = &this;
    }
    int data;
}

immutable(S)* makes() pure
{
    return new immutable S(0);
}

void main()
{
    S* s = makes(); // s is mutable and contains an immutable reference to
itself
    pragma(msg, typeof(s)); // mutable
    pragma(msg, typeof(s.s)); // immutable
    writefln("%s", s);   // same address
    writefln("%s", s.s); // same address
    //s.s.data = 7; // this is immutable
    s.data = 3; // but this is not!!!
}

On Sunday, 10 November 2013 at 13:46:20 UTC, Kenji Hara wrote:
> 2013/11/10 Daniel Davidson <nospam@spam.com>
>
>> With this design, is there no need then for struct constructors - or would
>> this be orthogonal or in addition to those?
>>
>
>
> Currently "constructing unique object" is already supported.
>
> http://dlang.org/class#constructors
>> If the constructor can create unique object (e.g. if it is pure), the
> object can be implicitly convertible to any qualifiers.
>
> Indeed, the definition could be improved by using "initializing unique
> expression" concept. But it is not directly related to the DIP49. So the
> answer is "this is orthogonal".

From this thread (http://forum.dlang.org/post/mailman.89.1383248384.9546.digitalmars-d-learn@puremagic.com) I was under the impression that const/immutable and postblits don't mix. This DIP seems to be trying to address that. One of the potential workarounds to this issue was the idea of struct copy constructors. This is what I was referring to. With this proposal, is there still a need for struct copy constructors?


Thanks
Dan

On 11/10/2013 04:41 PM, Daniel Davidson wrote:
> With this proposal, is there still a need for struct copy constructors?

No.

Am Sun, 10 Nov 2013 21:03:34 +0900
schrieb Kenji Hara <k.hara.pg@gmail.com>:

> So, separating "inout postblit' and 'unique postblit' may be reasonable.
> 
> (However, it seems to me that the syntax "this(inout this) inout;" looks
> weird...
> 
> Kenji Hara

I see the value in DIP49. There is a hole in the type system that needs a proper solution and it is astonishing that the "unique" concept is already there in D, but existed under the radar of public perception. I haven't read everything, but agree with making the language more fail safe any time.

I just find inout confusing as well. inout as a wildcard for const-ness is irritating enough, and with the double meaning as unique it might be difficult to read code using inout. Are the two concepts really coupled? Does it make the implementation of the DIP easier? Or should we have something like "unique" as a keyword?

-- 
Marco

2013/11/10 Daniel Murphy <yebblies@nospamgmail.com>

>
> "Kenji Hara" <k.hara.pg@gmail.com> wrote in message news:mailman.339.1384090714.9546.digitalmars-d@puremagic.com...
> > 2013/11/10 Daniel Murphy <yebblies@nospamgmail.com>
> >
> >> "Kenji Hara" <k.hara.pg@gmail.com> wrote in message news:mailman.336.1384083327.9546.digitalmars-d@puremagic.com...
> >> >
> >> > This is valid. Because not only strongly pure function will return
> >> > unique
> >> > object.
> >> >
> >> > For example:
> >> >  immutable(int)[] foo(int[] iarr) pure { ... }
> >> >  int[] marr = foo([1,2,3]);
> >> >  // foo will never return the arr argument (without unsafe cast).
> >> >
> >>
> >> This one is incorrect, the value returned from foo could be an immutable global.  The unique conversion is only capable of changing non-mutable
> to
> >> immutable, not the other way around.
> >>
> >
> > foo is pure, so it cannot return "immutable global".
> >
>
> Pure functions _can_ read immutable global variables.
>
> immutable x = [1, 2, 3];
>
> void main() pure
> {
>     assert(x[1] == 2);
> }
>
> Even if they couldn't, the immutable -> mutable conversion would still not be safe.
>
> edit: uh-oh this actually compiles.  Did you do this?
>
> eg
>
> import std.stdio;
>
> struct S
> {
>     immutable(S)* s;
>     this(int) immutable pure
>     {
>         s = &this;
>     }
>     int data;
> }
>
> immutable(S)* makes() pure
> {
>     return new immutable S(0);
> }
>
> void main()
> {
>     S* s = makes(); // s is mutable and contains an immutable reference to
> itself
>     pragma(msg, typeof(s)); // mutable
>     pragma(msg, typeof(s.s)); // immutable
>     writefln("%s", s);   // same address
>     writefln("%s", s.s); // same address
>     //s.s.data = 7; // this is immutable
>     s.data = 3; // but this is not!!!
> }
>

Ohhhh, it is definitely a bug. And that was introduced by MY pull requests
(I know that).
We must fix the type system hole ASAP!

https://d.puremagic.com/issues/show_bug.cgi?id=11503

Kenji Hara

2013/11/11 Daniel Davidson <nospam@spam.com>

> From this thread (http://forum.dlang.org/post/mailman.89.1383248384.9546. digitalmars-d-learn@puremagic.com) I was under the impression that const/immutable and postblits don't mix. This DIP seems to be trying to address that. One of the potential workarounds to this issue was the idea of struct copy constructors. This is what I was referring to. With this proposal, is there still a need for struct copy constructors?
>

1.5 years ago, I did asked to Andrei about the postbit issue.

<http://forum.dlang.org/thread/CAFDvkcvvL8GxHQB=Rw9pTm-uxOKzNGVQNDv9w5Os3SkQCc=DLQ@mail.gmail.com> http://forum.dlang.org/thread/CAFDvkcvvL8GxHQB=Rw9pTm-uxOKzNGVQNDv9w5Os3SkQCc=DLQ@mail.gmail.com


Andrei had thought that the issue will be fixed by adding "copy
constructor" in D.
However I believed that the postblit concept would be able to improved
more. So I couldn't convince about his thought.

DIP49 is the final conclusion of my belief. I can say that copy constructor is unnecessary in D.

Kenji Hara

2013/11/11 Marco Leise <Marco.Leise@gmx.de>

> Am Sun, 10 Nov 2013 21:03:34 +0900
> schrieb Kenji Hara <k.hara.pg@gmail.com>:
>
> > So, separating "inout postblit' and 'unique postblit' may be reasonable.
> >
> > (However, it seems to me that the syntax "this(inout this) inout;" looks
> > weird...
> >
> > Kenji Hara
>
> I see the value in DIP49. There is a hole in the type system that needs a proper solution and it is astonishing that the "unique" concept is already there in D, but existed under the radar of public perception. I haven't read everything, but agree with making the language more fail safe any time.
>

Indeed the "unique" concept is not yet enough described in D language
specification. But in recent (past one year or more), it has sometimes been
appeared onto various D features, and I had felt about it while working for
dmd.
The concept had been hidden between D's strong type system (transitive
const and immutability) and 'pure' function long time.


> I just find inout confusing as well. inout as a wildcard for const-ness is irritating enough, and with the double meaning as unique it might be difficult to read code using inout. Are the two concepts really coupled? Does it make the implementation of the DIP easier? Or should we have something like "unique" as a keyword?


I think rather it is interesting.
Inside inout function, we can treat the inout object as a Schrödinger's cat
(It may be mutable or immutable, or the middle of two == const). And the
necessary requirement to make a copy from an inout object had derived
"unique object" concept. I can agree it looks strange, but there's not any
failures of logic, as far as I know.

Adding a specific keyword for the concept would hurt the language orthogonality rather.

 Kenji Hara

On 11/11/13 8:30 PM, Kenji Hara wrote:
> 2013/11/11 Daniel Davidson <nospam@spam.com <mailto:nospam@spam.com>>
>
>      >From this thread
>     (http://forum.dlang.org/post/__mailman.89.1383248384.9546.__digitalmars-d-learn@puremagic.__com
>     <http://forum.dlang.org/post/mailman.89.1383248384.9546.digitalmars-d-learn@puremagic.com>)
>     I was under the impression that const/immutable and postblits don't
>     mix. This DIP seems to be trying to address that. One of the
>     potential workarounds to this issue was the idea of struct copy
>     constructors. This is what I was referring to. With this proposal,
>     is there still a need for struct copy constructors?
>
>
> 1.5 years ago, I did asked to Andrei about the postbit issue.
>
> <http://forum.dlang.org/thread/CAFDvkcvvL8GxHQB=Rw9pTm-uxOKzNGVQNDv9w5Os3SkQCc=DLQ@mail.gmail.com>
> http://forum.dlang.org/thread/CAFDvkcvvL8GxHQB=Rw9pTm-uxOKzNGVQNDv9w5Os3SkQCc=DLQ@mail.gmail.com
>
>
> Andrei had thought that the issue will be fixed by adding "copy
> constructor" in D.
> However I believed that the postblit concept would be able to improved
> more. So I couldn't convince about his thought.
>
> DIP49 is the final conclusion of my belief. I can say that copy
> constructor is unnecessary in D.
>
> Kenji Hara

I think it's great to address that problem (I'm not wed to any particular approach). My schedule has been crazy over the past few days, but I'll do my best to give a close read you DIP49.

Thanks,

Andrei