www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - immutable bug?

reply Manu <turkeyman gmail.com> writes:
--001a11c2a20cb8cc8904efb60599
Content-Type: text/plain; charset=UTF-8

I just managed to assign a const(char)[] to a string... caused crashes when
the original memory disappeared.

inout(char)[] todstr(inout(char)* cstr) pure nothrow
{
return cstr ? cstr[0 .. std.c.string.strlen(cstr)] : cstr[0 .. 0];
}

struct Data
{
char buffer[256] = void;
 property const(char)[] filename() const pure nothrow { return
todstr(buffer.ptr); }
}

struct MyThing
{
private this(in Data* p)
{
filename = p.filename; // *** Uh oh! assigned a const(char)[]  property to
a string! ***
}

string filename;
}

Surely that assignment shouldn't be legal? Shouldn't I need to idup?

--001a11c2a20cb8cc8904efb60599
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I just managed to assign a const(char)[] to a string... ca=
used crashes when the original memory disappeared.<div><br></div><div><div>=
<div>inout(char)[] todstr(inout(char)* cstr) pure nothrow</div><div>{</div>
<div><span class=3D"" style=3D"white-space:pre">	</span>return cstr ? cstr[=
0 .. std.c.string.strlen(cstr)] : cstr[0 .. 0];</div><div>}</div><div><br><=
/div><div>struct Data</div><div>{</div><div><span class=3D"" style=3D"white=
-space:pre">	</span>char buffer[256] =3D void;</div>
<div><span class=3D"" style=3D"white-space:pre">	</span> property const(cha=
r)[] filename() const pure nothrow<span class=3D"" style=3D"white-space:pre=
">	</span>{ return todstr(buffer.ptr); }</div><div>}</div><div><br></div><d=
iv>struct MyThing</div>
<div>{</div><div><span class=3D"" style=3D"white-space:pre">	</span>private=
 this(in Data* p)</div><div><span class=3D"" style=3D"white-space:pre">	</s=
pan>{</div><div><span class=3D"" style=3D"white-space:pre">		</span>filenam=
e =3D p.filename; // *** Uh oh! assigned a const(char)[]  property to a str=
ing! ***</div>
<div><span class=3D"" style=3D"white-space:pre">	</span>}</div><div><br></d=
iv><div><span class=3D"" style=3D"white-space:pre">	</span>string filename;=
</div><div>}</div></div></div><div><br></div><div>Surely that assignment sh=
ouldn&#39;t be legal? Shouldn&#39;t I need to idup?</div>
</div>

--001a11c2a20cb8cc8904efb60599--
Jan 11 2014
next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Saturday, 11 January 2014 at 18:29:36 UTC, Manu wrote:
 I just managed to assign a const(char)[] to a string... caused 
 crashes when
 the original memory disappeared.

 inout(char)[] todstr(inout(char)* cstr) pure nothrow
 {
 return cstr ? cstr[0 .. std.c.string.strlen(cstr)] : cstr[0 .. 
 0];
 }

 struct Data
 {
 char buffer[256] = void;
  property const(char)[] filename() const pure nothrow { return
 todstr(buffer.ptr); }
 }

 struct MyThing
 {
 private this(in Data* p)
 {
 filename = p.filename; // *** Uh oh! assigned a const(char)[] 
  property to
 a string! ***
 }

 string filename;
 }

 Surely that assignment shouldn't be legal? Shouldn't I need to 
 idup?

I don't know about the details of what is/isn't legal here, but the only reason the compiler accepts it is because filename is marked as pure.
Jan 11 2014
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/11/2014 08:16 PM, Maxim Fomin wrote:
 On Saturday, 11 January 2014 at 18:52:39 UTC, Adam D. Ruppe wrote:
 On Saturday, 11 January 2014 at 18:48:15 UTC, Maxim Fomin wrote:
 It is legal exactly because function is marked as pure. Result of
 pure function is implicitly convertible to immutable.

It shouldn't be here though... the reason it is implicitly convertable is that pure means the result is unique. But, with the hidden this pointer having a reference to the data as well, it obviously is not unique. I think the compiler should catch this; i'd call it a bug.

Creating undefined behavior is not a sufficient reason to be a bug. ...

Add a safe annotation and it is.
 Changelog mentions example with pure struct constructors which provide
 value implicitly castable to immutable. So, strictly speaking current
 behavior is conforming to spec.

 You can still argue that the example does not address the issue with
 'this' parameter, so code should be rejected (which should happen from
 safity aspect). I think this case was not considered when 'unique
 expression' was introduced, so it is yet another hole in type system (to
 be more precise, bug is in spec-language, not compiler).

It is an implementation bug. Implicit conversion to immutable is only supposed to work for strongly pure functions.
Jan 11 2014
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/12/14 2:49 AM, Peter Alexander wrote:
 On Sunday, 12 January 2014 at 02:11:18 UTC, Manu wrote:
 But pure functions can (and do) return their arguments, and it's
 obviously
 not a 'strongly pure' function. So I just can't see how the assertion
 that
 it should be unique stands?

That's the bug. Your function isn't strongly pure, so the result shouldn't be convertible to immutable and isn't necessarily unique. Only strongly pure functions can have results convertible to immutable.

Yep. Has this been placed in bugzilla? It's rather hi-pri. Andrei
Jan 12 2014
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Andrei Alexandrescu"  wrote in message 
news:laugbo$2jcq$3 digitalmars.com...
 Yep. Has this been placed in bugzilla? It's rather hi-pri.

If this isn't https://d.puremagic.com/issues/show_bug.cgi?id=11503 - it most likely has the same cause.
Jan 12 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/12/14 8:46 AM, Daniel Murphy wrote:
 "Andrei Alexandrescu"  wrote in message
 news:laugbo$2jcq$3 digitalmars.com...
 Yep. Has this been placed in bugzilla? It's rather hi-pri.

If this isn't https://d.puremagic.com/issues/show_bug.cgi?id=11503 - it most likely has the same cause.

Put $150 on this. https://www.bountysource.com/issues/1325974-type-system-breaking-caused-by-implicit-conversion-for-the-value-returned-from-pure-function Andrei
Jan 12 2014
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 01/12/2014 07:10 PM, Andrei Alexandrescu wrote:
 On 1/12/14 8:46 AM, Daniel Murphy wrote:
 "Andrei Alexandrescu"  wrote in message
 news:laugbo$2jcq$3 digitalmars.com...
 Yep. Has this been placed in bugzilla? It's rather hi-pri.

If this isn't https://d.puremagic.com/issues/show_bug.cgi?id=11503 - it most likely has the same cause.

Put $150 on this. https://www.bountysource.com/issues/1325974-type-system-breaking-caused-by-implicit-conversion-for-the-value-returned-from-pure-function Andrei

This issue was trivial, and yet was assigned a higher bounty than e.g. fixing CTFE performance, which requires a large investment as far as I understand. This raises the question of how bountied issues are selected. There are other serious problems with the type system implementation, eg: https://d.puremagic.com/issues/show_bug.cgi?id=9149 https://d.puremagic.com/issues/show_bug.cgi?id=10376 https://d.puremagic.com/issues/show_bug.cgi?id=9148 On a related note, I think it makes no sense to put a bounty on the "Object not const-correct" issue. What would someone be required to do in order to get the bounty for that issue?
Jan 12 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/12/14 12:35 PM, Timon Gehr wrote:
 On 01/12/2014 07:10 PM, Andrei Alexandrescu wrote:
 On 1/12/14 8:46 AM, Daniel Murphy wrote:
 "Andrei Alexandrescu"  wrote in message
 news:laugbo$2jcq$3 digitalmars.com...
 Yep. Has this been placed in bugzilla? It's rather hi-pri.

If this isn't https://d.puremagic.com/issues/show_bug.cgi?id=11503 - it most likely has the same cause.

Put $150 on this. https://www.bountysource.com/issues/1325974-type-system-breaking-caused-by-implicit-conversion-for-the-value-returned-from-pure-function Andrei

This issue was trivial, and yet was assigned a higher bounty than e.g. fixing CTFE performance, which requires a large investment as far as I understand. This raises the question of how bountied issues are selected.

I select them with a focus on impact. Clearly the process could be improved. There are other serious problems with the type system
 implementation, eg:

 https://d.puremagic.com/issues/show_bug.cgi?id=9149
 https://d.puremagic.com/issues/show_bug.cgi?id=10376
 https://d.puremagic.com/issues/show_bug.cgi?id=9148

Thanks, will take those under advisement. FWIW there's been a thread taking suggestions.
 On a related note, I think it makes no sense to put a bounty on the
 "Object not const-correct" issue. What would someone be required to do
 in order to get the bounty for that issue?

Make sure we have a complete solution for invoking Object's methods against const and immutable Objects? Andrei
Jan 12 2014
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/12/2014 11:51 PM, Andrei Alexandrescu wrote:
 ...
 Put $150 on this.
 https://www.bountysource.com/issues/1325974-type-system-breaking-caused-by-implicit-conversion-for-the-value-returned-from-pure-function




 Andrei

This issue was trivial, and yet was assigned a higher bounty than e.g. fixing CTFE performance, which requires a large investment as far as I understand. This raises the question of how bountied issues are selected.

I select them with a focus on impact. Clearly the process could be improved. ...

I see. FWIW it _did_ get an issue fixed.
   There are other serious problems with the type system
 implementation, eg:

 https://d.puremagic.com/issues/show_bug.cgi?id=9149
 https://d.puremagic.com/issues/show_bug.cgi?id=10376
 https://d.puremagic.com/issues/show_bug.cgi?id=9148

Thanks, will take those under advisement. FWIW there's been a thread taking suggestions. ...

(I know; at that time I didn't think those issues would qualify. :o))
 On a related note, I think it makes no sense to put a bounty on the
 "Object not const-correct" issue. What would someone be required to do
 in order to get the bounty for that issue?

Make sure we have a complete solution for invoking Object's methods against const and immutable Objects? Andrei

Wasn't there a consensus that Object's methods are going away?
Jan 12 2014
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/12/2014 11:49 AM, Peter Alexander wrote:
 Also, I was under the impression a 'strongly pure' function's arguments
 only need to be const, not necessarily immutable. Purity says something
 about the transformation performed by the function, nothing about the
 data
 it operates on.
 Why should all arguments need to be immutable?

You don't need immutable arguments for purity, just strong purity. It's a stronger guarantee, more than normally guaranteed. Think of strong purity as pure + referentially transparent. Sorry, yes you're right, they only need to be const. And it is only if you return a mutable value that the result becomes convertible to immutable. int* f(const(int)* x); // convertible const(int)* f(const(int)* x); // not-convertible ...

(I assume you meant those to be pure.)
 This is safe in the first instance because the result could not have
 come from x due to x being const. In the second instance, the result
 could have come from x, so it cannot be implicitly converted to immutable.

Well, currently things are supposed to be as follows: 1. A strongly pure callable is a pure callable whose parameter types implicitly convert to immutable. 2. The result of a call to a strongly pure callable implicitly converts to immutable. The following vastly more general rule would still be sound and also capture your case: - The result of a call to a pure callable, where all arguments whose corresponding parameter types are incompatible with the result type implicitly convert to immutable (shared), implicitly converts to immutable (shared). (Incompatibility should probably just be incompatibility of qualifiers.)
Jan 12 2014
prev sibling next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Saturday, 11 January 2014 at 18:43:39 UTC, John Colvin wrote:
 I don't know about the details of what is/isn't legal here, but 
 the only reason the compiler accepts it is because filename is 
 marked as pure.

It is legal exactly because function is marked as pure. Result of pure function is implicitly convertible to immutable.
Jan 11 2014
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 11 January 2014 at 18:48:15 UTC, Maxim Fomin wrote:
 It is legal exactly because function is marked as pure. Result 
 of pure function is implicitly convertible to immutable.

It shouldn't be here though... the reason it is implicitly convertable is that pure means the result is unique. But, with the hidden this pointer having a reference to the data as well, it obviously is not unique. I think the compiler should catch this; i'd call it a bug.
Jan 11 2014
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Saturday, 11 January 2014 at 18:48:15 UTC, Maxim Fomin wrote:
 On Saturday, 11 January 2014 at 18:43:39 UTC, John Colvin wrote:
 I don't know about the details of what is/isn't legal here, 
 but the only reason the compiler accepts it is because 
 filename is marked as pure.

It is legal exactly because function is marked as pure. Result of pure function is implicitly convertible to immutable.

I had heard this mentioned before; is it true in all cases? Even when the function returns a reference to external data?
Jan 11 2014
prev sibling next sibling parent "anonymous" <anonymous example.com> writes:
On Saturday, 11 January 2014 at 18:29:36 UTC, Manu wrote:
 I just managed to assign a const(char)[] to a string... caused 
 crashes when
 the original memory disappeared.

 inout(char)[] todstr(inout(char)* cstr) pure nothrow
 {
 return cstr ? cstr[0 .. std.c.string.strlen(cstr)] : cstr[0 .. 
 0];
 }

 struct Data
 {
 char buffer[256] = void;
  property const(char)[] filename() const pure nothrow { return
 todstr(buffer.ptr); }
 }

 struct MyThing
 {
 private this(in Data* p)
 {
 filename = p.filename; // *** Uh oh! assigned a const(char)[] 
  property to
 a string! ***
 }

 string filename;
 }

 Surely that assignment shouldn't be legal? Shouldn't I need to 
 idup?

Simplified: const(char)[] slice(ref const char[1] c) pure nothrow { return c[]; } void main() { char[1] m = "."; immutable i = slice(m); // should not compile assert(i == "."); m = "!"; // uh-oh assert(i == "."); // fails }
Jan 11 2014
prev sibling next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Saturday, 11 January 2014 at 18:52:39 UTC, Adam D. Ruppe wrote:
 On Saturday, 11 January 2014 at 18:48:15 UTC, Maxim Fomin wrote:
 It is legal exactly because function is marked as pure. Result 
 of pure function is implicitly convertible to immutable.

It shouldn't be here though... the reason it is implicitly convertable is that pure means the result is unique. But, with the hidden this pointer having a reference to the data as well, it obviously is not unique. I think the compiler should catch this; i'd call it a bug.

Creating undefined behavior is not a sufficient reason to be a bug. Changelog mentions example with pure struct constructors which provide value implicitly castable to immutable. So, strictly speaking current behavior is conforming to spec. You can still argue that the example does not address the issue with 'this' parameter, so code should be rejected (which should happen from safity aspect). I think this case was not considered when 'unique expression' was introduced, so it is yet another hole in type system (to be more precise, bug is in spec-language, not compiler).
Jan 11 2014
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Saturday, 11 January 2014 at 21:16:55 UTC, Timon Gehr wrote:
 It is an implementation bug. Implicit conversion to immutable 
 is only supposed to work for strongly pure functions.

Can someone that knows all the details of the purity strength semantic differences please open a PR to get some documentation in the spec? I've updated this bug with a comment: https://d.puremagic.com/issues/show_bug.cgi?id=7456
Jan 11 2014
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--047d7b33cdfcd31d3304efbb577a
Content-Type: text/plain; charset=UTF-8

On 12 January 2014 04:52, Adam D. Ruppe <destructionator gmail.com> wrote:

 On Saturday, 11 January 2014 at 18:48:15 UTC, Maxim Fomin wrote:

 It is legal exactly because function is marked as pure. Result of pure
 function is implicitly convertible to immutable.

It shouldn't be here though... the reason it is implicitly convertable is that pure means the result is unique.

Can you explain how this is true? I can't see anything about the concept of purity that suggests the result should be unique... Pure just means given the same inputs, it will produce the same outputs; external state can't affect the calculation. In this case, that's perfectly true. 'this' is just a function arg; it's not mutated by external state (or at all), given the same this, it will return the same thing every time. That doesn't make any claims about what 'this' is though, and whether it's immutable or 'unique' or whatever. It just promises to transform it in an identical way given the same inputs... ? But, with the hidden this pointer having a reference to the data as well,
 it obviously is not unique. I think the compiler should catch this; i'd
 call it a bug.

--047d7b33cdfcd31d3304efbb577a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 1= 2 January 2014 04:52, Adam D. Ruppe <span dir=3D"ltr">&lt;<a href=3D"mailto= :destructionator gmail.com" target=3D"_blank">destructionator gmail.com</a>= &gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"im">On Saturday, 11 January 20= 14 at 18:48:15 UTC, Maxim Fomin wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> It is legal exactly because function is marked as pure. Result of pure func= tion is implicitly convertible to immutable.<br> </blockquote> <br></div> It shouldn&#39;t be here though... the reason it is implicitly convertable = is that pure means the result is unique.</blockquote><div><br></div><div>Ca= n you explain how this is true? I can&#39;t see anything about the concept = of purity that suggests the result should be unique...</div> <div>Pure just means given the same inputs, it will produce the same output= s; external state can&#39;t affect the calculation.</div><div><br></div><di= v>In this case, that&#39;s perfectly true. &#39;this&#39; is just a functio= n arg; it&#39;s not mutated by external state (or at all), given the same t= his, it will return the same thing every time.</div> <div>That doesn&#39;t make any claims about what &#39;this&#39; is though, = and whether it&#39;s immutable or &#39;unique&#39; or whatever. It just pro= mises to transform it in an identical way given the same inputs...</div> <div>?</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margi= n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> But, with the hi= dden this pointer having a reference to the data as well, it obviously is n= ot unique. I think the compiler should catch this; i&#39;d call it a bug.<b= r> </blockquote></div><br></div></div> --047d7b33cdfcd31d3304efbb577a--
Jan 11 2014
prev sibling next sibling parent "David Nadlinger" <code klickverbot.at> writes:
On Sunday, 12 January 2014 at 00:50:30 UTC, Manu wrote:
 On 12 January 2014 04:52, Adam D. Ruppe
 It shouldn't be here though... the reason it is implicitly 
 convertable is
 that pure means the result is unique.


I touched on the topic in a short section of my old purity article: http://klickverbot.at/blog/2012/05/purity-in-d/#_and___again David
Jan 11 2014
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Sunday, 12 January 2014 at 00:50:30 UTC, Manu wrote:
 On 12 January 2014 04:52, Adam D. Ruppe 
 <destructionator gmail.com> wrote:

 On Saturday, 11 January 2014 at 18:48:15 UTC, Maxim Fomin 
 wrote:

 It is legal exactly because function is marked as pure. 
 Result of pure
 function is implicitly convertible to immutable.

It shouldn't be here though... the reason it is implicitly convertable is that pure means the result is unique.

Can you explain how this is true? I can't see anything about the concept of purity that suggests the result should be unique... Pure just means given the same inputs, it will produce the same outputs; external state can't affect the calculation.

How could the result not be unique, or at least immutable? Pure functions cannot read mutable global state, so any global state returned must be immutable. Strong pure functions can also only have immutable arguments, so anything returned from those will be immutable. The only other thing that can be returned must be created within the function, which will be unique, and safely converted to immutable.
Jan 11 2014
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--089e0149cd5ee6d4a404efbc78cf
Content-Type: text/plain; charset=UTF-8

On 12 January 2014 11:05, Peter Alexander <peter.alexander.au gmail.com>wrote:

 On Sunday, 12 January 2014 at 00:50:30 UTC, Manu wrote:

 On 12 January 2014 04:52, Adam D. Ruppe <destructionator gmail.com>
 wrote:

  On Saturday, 11 January 2014 at 18:48:15 UTC, Maxim Fomin wrote:
  It is legal exactly because function is marked as pure. Result of pure
 function is implicitly convertible to immutable.

that pure means the result is unique.

Can you explain how this is true? I can't see anything about the concept of purity that suggests the result should be unique... Pure just means given the same inputs, it will produce the same outputs; external state can't affect the calculation.

How could the result not be unique, or at least immutable? Pure functions cannot read mutable global state, so any global state returned must be immutable. Strong pure functions can also only have immutable arguments, so anything returned from those will be immutable. The only other thing that can be returned must be created within the function, which will be unique, and safely converted to immutable.

But pure functions can (and do) return their arguments, and it's obviously not a 'strongly pure' function. So I just can't see how the assertion that it should be unique stands? Also, I was under the impression a 'strongly pure' function's arguments only need to be const, not necessarily immutable. Purity says something about the transformation performed by the function, nothing about the data it operates on. Why should all arguments need to be immutable? --089e0149cd5ee6d4a404efbc78cf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 1= 2 January 2014 11:05, Peter Alexander <span dir=3D"ltr">&lt;<a href=3D"mail= to:peter.alexander.au gmail.com" target=3D"_blank">peter.alexander.au gmail= .com</a>&gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"im">On Sunday, 12 January 2014= at 00:50:30 UTC, Manu wrote:<br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"><div class=3D"im"> On 12 January 2014 04:52, Adam D. Ruppe &lt;<a href=3D"mailto:destructionat= or gmail.com" target=3D"_blank">destructionator gmail.com</a>&gt; wrote:<br=

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On Saturday, 11 January 2014 at 18:48:15 UTC, Maxim Fomin wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> It is legal exactly because function is marked as pure. Result of pure<br> function is implicitly convertible to immutable.<br> <br> </blockquote> <br> It shouldn&#39;t be here though... the reason it is implicitly convertable = is<br> that pure means the result is unique.<br> </blockquote> <br> <br></div><div class=3D"im"> Can you explain how this is true? I can&#39;t see anything about the concep= t of<br> purity that suggests the result should be unique...<br> Pure just means given the same inputs, it will produce the same outputs;<br=

</div></blockquote> <br> How could the result not be unique, or at least immutable? Pure functions c= annot read mutable global state, so any global state returned must be immut= able. Strong pure functions can also only have immutable arguments, so anyt= hing returned from those will be immutable. The only other thing that can b= e returned must be created within the function, which will be unique, and s= afely converted to immutable.<br> </blockquote></div></div><div class=3D"gmail_extra"><br></div><div class=3D= "gmail_extra">But pure functions can (and do) return their arguments, and i= t&#39;s obviously not a &#39;strongly pure&#39; function. So I just can&#39= ;t see how the assertion that it should be unique stands?</div> <div class=3D"gmail_extra">Also, I was under the impression a &#39;strongly= pure&#39; function&#39;s arguments only need to be const, not necessarily = immutable. Purity says something about the transformation performed by the = function, nothing about the data it operates on.</div> <div class=3D"gmail_extra">Why should all arguments need to be immutable?</= div></div> --089e0149cd5ee6d4a404efbc78cf--
Jan 11 2014
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Sunday, 12 January 2014 at 02:11:18 UTC, Manu wrote:
 But pure functions can (and do) return their arguments, and 
 it's obviously
 not a 'strongly pure' function. So I just can't see how the 
 assertion that
 it should be unique stands?

That's the bug. Your function isn't strongly pure, so the result shouldn't be convertible to immutable and isn't necessarily unique. Only strongly pure functions can have results convertible to immutable.
 Also, I was under the impression a 'strongly pure' function's 
 arguments
 only need to be const, not necessarily immutable. Purity says 
 something
 about the transformation performed by the function, nothing 
 about the data
 it operates on.
 Why should all arguments need to be immutable?

You don't need immutable arguments for purity, just strong purity. It's a stronger guarantee, more than normally guaranteed. Think of strong purity as pure + referentially transparent. Sorry, yes you're right, they only need to be const. And it is only if you return a mutable value that the result becomes convertible to immutable. int* f(const(int)* x); // convertible const(int)* f(const(int)* x); // not-convertible This is safe in the first instance because the result could not have come from x due to x being const. In the second instance, the result could have come from x, so it cannot be implicitly converted to immutable.
Jan 12 2014
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
On Sunday, 12 January 2014 at 02:11:18 UTC, Manu wrote:
 Also, I was under the impression a 'strongly pure' function's 
 arguments
 only need to be const, not necessarily immutable. Purity says 
 something
 about the transformation performed by the function, nothing 
 about the data
 it operates on.
 Why should all arguments need to be immutable?

Your definition of purity states it clearly that the purity depends on the mutability of the input data.
Jan 12 2014
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--089e012940d8f6808104efc94127
Content-Type: text/plain; charset=UTF-8

On 13 January 2014 02:37, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org
 wrote:

 On 1/12/14 2:49 AM, Peter Alexander wrote:

 On Sunday, 12 January 2014 at 02:11:18 UTC, Manu wrote:

 But pure functions can (and do) return their arguments, and it's
 obviously
 not a 'strongly pure' function. So I just can't see how the assertion
 that
 it should be unique stands?

That's the bug. Your function isn't strongly pure, so the result shouldn't be convertible to immutable and isn't necessarily unique. Only strongly pure functions can have results convertible to immutable.

Yep. Has this been placed in bugzilla? It's rather hi-pri.

I wasn't sure if it was definitely a bug. Certainly seemed like one though. https://d.puremagic.com/issues/show_bug.cgi?id=11908 --089e012940d8f6808104efc94127 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 1= 3 January 2014 02:37, Andrei Alexandrescu <span dir=3D"ltr">&lt;<a href=3D"= mailto:SeeWebsiteForEmail erdani.org" target=3D"_blank">SeeWebsiteForEmail = erdani.org</a>&gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"><div class=3D"im">On 1/12/14 2:49 AM, Peter Alexander wrot= e:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> On Sunday, 12 January 2014 at 02:11:18 UTC, Manu wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> But pure functions can (and do) return their arguments, and it&#39;s<br> obviously<br> not a &#39;strongly pure&#39; function. So I just can&#39;t see how the ass= ertion<br> that<br> it should be unique stands?<br> </blockquote> <br> That&#39;s the bug. Your function isn&#39;t strongly pure, so the result<br=

Only<br> strongly pure functions can have results convertible to immutable.<br> </blockquote> <br></div> Yep. Has this been placed in bugzilla? It&#39;s rather hi-pri.</blockquote>= <div><br></div><div>I wasn&#39;t sure if it was definitely a bug. Certainly= seemed like one though.</div><div><br></div><div><a href=3D"https://d.pure= magic.com/issues/show_bug.cgi?id=3D11908">https://d.puremagic.com/issues/sh= ow_bug.cgi?id=3D11908</a><br> </div></div></div></div> --089e012940d8f6808104efc94127--
Jan 12 2014
prev sibling next sibling parent "David Nadlinger" <code klickverbot.at> writes:
On Sunday, 12 January 2014 at 18:09:59 UTC, Andrei Alexandrescu 
wrote:
 Put $150 on this. 
 https://www.bountysource.com/issues/1325974-type-system-breaking-caused-by-implicit-conversion-for-the-value-returned-from-pure-function

I posted a fix for this issue (i.e. the one on which the bounty was set). Now tackling Manu's example, which turns out to exhibit a slightly different bug. David
Jan 12 2014
prev sibling next sibling parent reply "Johnny Walking" <jw redlabel.com> writes:
On Saturday, 11 January 2014 at 18:29:36 UTC, Manu wrote:
...

I'm just a bit confused, but recently I've seen many topics from Manu and problems which he's facing with D. So my question is: You don't had any problems when coding "Remedy's" 3D engine integration with D back then? (http://dconf.org/2013/talks/evans_1.html) or am I missing something?
Jan 12 2014
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/12/2014 10:06 PM, Johnny Walking wrote:
 On Saturday, 11 January 2014 at 18:29:36 UTC, Manu wrote:
 ...

I'm just a bit confused, but recently I've seen many topics from Manu and problems which he's facing with D. So my question is: You don't had any problems when coding "Remedy's" 3D engine integration with D back then? (http://dconf.org/2013/talks/evans_1.html) or am I missing something?

http://en.wikipedia.org/wiki/Baader-Meinhof_phenomenon
Jan 12 2014
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--047d7b5d340c3c97f104efcfb35f
Content-Type: text/plain; charset=UTF-8

On 13 January 2014 07:06, Johnny Walking <jw redlabel.com> wrote:

 On Saturday, 11 January 2014 at 18:29:36 UTC, Manu wrote:

 ...

I'm just a bit confused, but recently I've seen many topics from Manu and problems which he's facing with D. So my question is: You don't had any problems when coding "Remedy's" 3D engine integration with D back then? (http://dconf.org/2013/talks/evans_1.html) or am I missing something?

I was doing very different work at that point, stressing totally different parts of the language - mostly meta stuff. And believe me, I had bugs, lots of them. I also had a direct hotline to Walter... I don't feel I have the authority to pester him directly or as frequently now ;) What doesn't come across in my posts is that the D experience today is _so much_ better than it was while I was doing the Remedy work. It's come a long way in terms of quality in the last 1-2 years, and generally gets better every day. I often remark to myself how relatively rare to is to run into compiler bugs today. But you know what seems to reliably make it better? Complaining about it. Well, that... and the work of all the awesome contributors! :) Silently adding workarounds to your code, and dropping a bug somewhere has significantly lesser effect. There's no other functional sense of priority I'm aware of, voting on issues has apparently little meaning. Issues that seem to get the most buzz in the forum seem to get fixed the fastest. I'm good as making noise ;) --047d7b5d340c3c97f104efcfb35f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 1= 3 January 2014 07:06, Johnny Walking <span dir=3D"ltr">&lt;<a href=3D"mailt= o:jw redlabel.com" target=3D"_blank">jw redlabel.com</a>&gt;</span> wrote:<= br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord= er-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:soli= d;padding-left:1ex"> <div class=3D"im">On Saturday, 11 January 2014 at 18:29:36 UTC, Manu wrote:= <br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b= order-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:s= olid;padding-left:1ex"> ...<br> </blockquote> <br> I&#39;m =C2=A0just a bit confused, but recently I&#39;ve seen many topics f= rom<br> Manu and problems which he&#39;s facing with D.<br> <br> So my question is: You don&#39;t had any problems when coding<br> &quot;Remedy&#39;s&quot; 3D engine integration with D back then?<br> (<a href=3D"http://dconf.org/2013/talks/evans_1.html" target=3D"_blank">htt= p://dconf.org/2013/talks/<u></u>evans_1.html</a>) or am I missing<br> something?<br> </blockquote></div><br></div><div class=3D"gmail_extra">I was doing very di= fferent work at that point, stressing totally different parts of the langua= ge - mostly meta stuff. And believe me, I had bugs, lots of them.</div><div= class=3D"gmail_extra"> I also had a direct hotline to Walter... I don&#39;t feel I have the author= ity to pester him directly or as frequently now ;)</div><div class=3D"gmail= _extra"><br></div><div class=3D"gmail_extra">What doesn&#39;t come across i= n my posts is that the D experience today is _so much_ better than it was w= hile I was doing the Remedy work. It&#39;s come a long way in terms of qual= ity in the last 1-2 years, and generally gets better every day.</div> <div class=3D"gmail_extra">I often remark to myself how relatively rare to = is to run into compiler bugs today.</div><div class=3D"gmail_extra"><br></d= iv><div class=3D"gmail_extra">But you know what seems to=C2=A0reliably=C2= =A0make it better? Complaining about it. Well, that... and the work of all = the awesome contributors! :)</div> <div class=3D"gmail_extra">Silently adding workarounds to your code, and dr= opping a bug somewhere has significantly lesser effect. There&#39;s no othe= r functional sense of priority I&#39;m aware of, voting on issues has appar= ently little meaning. Issues that seem to get the most buzz in the forum se= em to get fixed the fastest. I&#39;m good as making noise ;)</div> </div> --047d7b5d340c3c97f104efcfb35f--
Jan 12 2014
prev sibling next sibling parent "Rikki Cattermole" <alphaglosined gmail.com> writes:
On Monday, 13 January 2014 at 01:07:56 UTC, Manu wrote:
 On 13 January 2014 07:06, Johnny Walking <jw redlabel.com> 
 wrote:

 On Saturday, 11 January 2014 at 18:29:36 UTC, Manu wrote:

 ...

I'm just a bit confused, but recently I've seen many topics from Manu and problems which he's facing with D. So my question is: You don't had any problems when coding "Remedy's" 3D engine integration with D back then? (http://dconf.org/2013/talks/evans_1.html) or am I missing something?

I was doing very different work at that point, stressing totally different parts of the language - mostly meta stuff. And believe me, I had bugs, lots of them. I also had a direct hotline to Walter... I don't feel I have the authority to pester him directly or as frequently now ;) What doesn't come across in my posts is that the D experience today is _so much_ better than it was while I was doing the Remedy work. It's come a long way in terms of quality in the last 1-2 years, and generally gets better every day. I often remark to myself how relatively rare to is to run into compiler bugs today. But you know what seems to reliably make it better? Complaining about it. Well, that... and the work of all the awesome contributors! :) Silently adding workarounds to your code, and dropping a bug somewhere has significantly lesser effect. There's no other functional sense of priority I'm aware of, voting on issues has apparently little meaning. Issues that seem to get the most buzz in the forum seem to get fixed the fastest. I'm good as making noise ;)

I know the feeling with Dvorm and Cmsed's router. The amount of bugs I hit are horrendous. I'm not complaining about it or reporting them mainly because a) not on a head build and b) I'm literally pushing the compiler to its limits in some areas. Maybe once next version and it has all been announced I'll start on getting the common issues that a user might experience reported. But I suspect with these ones they aren't gonna be a simple fix. Although I am glad I am doing it now rather than a year ago. Mainly because I've learnt so much since then from the D community. I have to say more than any other in my past.
Jan 12 2014
prev sibling next sibling parent "David Nadlinger" <code klickverbot.at> writes:
On Sunday, 12 January 2014 at 19:36:10 UTC, David Nadlinger wrote:
 On Sunday, 12 January 2014 at 18:09:59 UTC, Andrei Alexandrescu 
 wrote:
 Put $150 on this. 
 https://www.bountysource.com/issues/1325974-type-system-breaking-caused-by-implicit-conversion-for-the-value-returned-from-pure-function

I posted a fix for this issue (i.e. the one on which the bounty was set). Now tackling Manu's example, which turns out to exhibit a slightly different bug.

Filed as https://d.puremagic.com/issues/show_bug.cgi?id=11909, fix at https://github.com/D-Programming-Language/dmd/pull/3085. David
Jan 12 2014
prev sibling next sibling parent Brad Roberts <braddr puremagic.com> writes:
On 1/12/14 5:46 PM, Rikki Cattermole wrote:
 I know the feeling with Dvorm and Cmsed's router. The amount of bugs I hit are
horrendous. I'm not
 complaining about it or reporting them mainly because a) not on a head build
and b) I'm literally
 pushing the compiler to its limits in some areas.

Please, report all of the bugs. An unreported bug is rather less likely to be fixed. We'd much rather have duplicate reports than no reports. Dups are fairly easy to deal with.
Jan 12 2014
prev sibling next sibling parent "Rikki Cattermole" <alphaglosined gmail.com> writes:
On Monday, 13 January 2014 at 03:45:07 UTC, Brad Roberts wrote:
 On 1/12/14 5:46 PM, Rikki Cattermole wrote:
 I know the feeling with Dvorm and Cmsed's router. The amount 
 of bugs I hit are horrendous. I'm not
 complaining about it or reporting them mainly because a) not 
 on a head build and b) I'm literally
 pushing the compiler to its limits in some areas.

Please, report all of the bugs. An unreported bug is rather less likely to be fixed. We'd much rather have duplicate reports than no reports. Dups are fairly easy to deal with.

I do agree that they need to be dealt with. I'm just not prepared right now to sort out getting the case for each sort of issue I have.
Jan 12 2014
prev sibling next sibling parent Guido Kollerie <guido kollerie.com> writes:
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

On 13/01/14 02:07 , Manu wrote:

 What doesn't come across in my posts is that the D experience today is
 _so much_ better than it was while I was doing the Remedy work. It's
 come a long way in terms of quality in the last 1-2 years, and generall=

 gets better every day.
 I often remark to myself how relatively rare to is to run into compiler=

 bugs today.

That's good to hear as for someone that's just (at this stage) lurking=20 around on this mailinglist it's easy to get a very different impression=20 based on the type of discussions. --=20 Guido Kollerie
Jan 13 2014
prev sibling parent Manu <turkeyman gmail.com> writes:
--047d7bd6afcc27b19704efd84ef8
Content-Type: text/plain; charset=UTF-8

On 13 January 2014 20:03, Guido Kollerie <guido kollerie.com> wrote:

 On 13/01/14 02:07 , Manu wrote:

  What doesn't come across in my posts is that the D experience today is
 _so much_ better than it was while I was doing the Remedy work. It's
 come a long way in terms of quality in the last 1-2 years, and generally
 gets better every day.
 I often remark to myself how relatively rare to is to run into compiler
 bugs today.

That's good to hear as for someone that's just (at this stage) lurking around on this mailinglist it's easy to get a very different impression based on the type of discussions.

Well it's a dev forum. I'm sure it's easy to get that impression, since almost all discussion is about things that are broken and people are working on, or ideas for improvement ;) --047d7bd6afcc27b19704efd84ef8 Content-Type: text/html; charset=UTF-8 <div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 13 January 2014 20:03, Guido Kollerie <span dir="ltr">&lt;<a href="mailto:guido kollerie.com" target="_blank">guido kollerie.com</a>&gt;</span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 13/01/14 02:07 , Manu wrote:<br> <br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> What doesn&#39;t come across in my posts is that the D experience today is<br> _so much_ better than it was while I was doing the Remedy work. It&#39;s<br> come a long way in terms of quality in the last 1-2 years, and generally<br> gets better every day.<br> I often remark to myself how relatively rare to is to run into compiler<br> bugs today.<br> </blockquote> <br></div> That&#39;s good to hear as for someone that&#39;s just (at this stage) lurking around on this mailinglist it&#39;s easy to get a very different impression based on the type of discussions.</blockquote><div><br></div><div> Well it&#39;s a dev forum. I&#39;m sure it&#39;s easy to get that impression, since almost all discussion is about things that are broken and people are working on, or ideas for improvement ;)</div></div></div></div> --047d7bd6afcc27b19704efd84ef8--
Jan 13 2014