• Manu (22/22) Jan 11 2014 I just managed to assign a const(char)[] to a string... caused crashes w...
• John Colvin (4/30) Jan 11 2014 I don't know about the details of what is/isn't legal here, but
• Maxim Fomin (3/6) Jan 11 2014 It is legal exactly because function is marked as pure. Result of
• Adam D. Ruppe (6/8) Jan 11 2014 It shouldn't be here though... the reason it is implicitly
• Maxim Fomin (12/20) Jan 11 2014 Creating undefined behavior is not a sufficient reason to be a
• Timon Gehr (4/23) Jan 11 2014 It is an implementation bug. Implicit conversion to immutable is only
• Peter Alexander (6/8) Jan 11 2014 Can someone that knows all the details of the purity strength
• Manu (13/21) Jan 11 2014 Can you explain how this is true? I can't see anything about the concept...
• David Nadlinger (5/10) Jan 11 2014 I touched on the topic in a short section of my old purity
• Peter Alexander (8/27) Jan 11 2014 How could the result not be unique, or at least immutable? Pure
• Manu (9/36) Jan 11 2014 But pure functions can (and do) return their arguments, and it's obvious...
• Peter Alexander (17/30) Jan 12 2014 That's the bug. Your function isn't strongly pure, so the result
• Andrei Alexandrescu (3/12) Jan 12 2014 Yep. Has this been placed in bugzilla? It's rather hi-pri.
• Daniel Murphy (4/5) Jan 12 2014 If this isn't https://d.puremagic.com/issues/show_bug.cgi?id=11503 - it ...
• Andrei Alexandrescu (4/9) Jan 12 2014 Put $150 on this.
• David Nadlinger (7/9) Jan 12 2014 I posted a fix for this issue (i.e. the one on which the bounty
• David Nadlinger (4/12) Jan 12 2014 Filed as https://d.puremagic.com/issues/show_bug.cgi?id=11909,
• Timon Gehr (12/23) Jan 12 2014 This issue was trivial, and yet was assigned a higher bounty than e.g.
• Andrei Alexandrescu (9/36) Jan 12 2014 I select them with a focus on impact. Clearly the process could be
• Timon Gehr (4/36) Jan 12 2014 (I know; at that time I didn't think those issues would qualify. :o))
• Manu (3/19) Jan 12 2014 I wasn't sure if it was definitely a bug. Certainly seemed like one thou...
• Timon Gehr (14/32) Jan 12 2014 Well, currently things are supposed to be as follows:
• Kagamin (3/11) Jan 12 2014 Your definition of purity states it clearly that the purity
• John Colvin (3/10) Jan 11 2014 I had heard this mentioned before; is it true in all cases?
• anonymous (14/40) Jan 11 2014 Simplified:
• Johnny Walking (7/8) Jan 12 2014 I'm just a bit confused, but recently I've seen many topics from
• Timon Gehr (2/10) Jan 12 2014 http://en.wikipedia.org/wiki/Baader-Meinhof_phenomenon
• Manu (19/28) Jan 12 2014 I was doing very different work at that point, stressing totally differe...
• Rikki Cattermole (12/58) Jan 12 2014 I know the feeling with Dvorm and Cmsed's router. The amount of
• Brad Roberts (3/6) Jan 12 2014 Please, report all of the bugs. An unreported bug is rather less likely...
• Rikki Cattermole (4/13) Jan 12 2014 I do agree that they need to be dealt with. I'm just not prepared
• Guido Kollerie (7/13) Jan 13 2014 That's good to hear as for someone that's just (at this stage) lurking=2...
• Manu (4/15) Jan 13 2014 Well it's a dev forum. I'm sure it's easy to get that impression, since

Manu <turkeyman gmail.com> writes:

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?

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

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

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

"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).

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.

"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

Manu <turkeyman gmail.com> writes:

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.

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

 Can you explain how this is true?

I touched on the topic in a short section of my old purity 
article: 


David

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

Manu <turkeyman gmail.com> writes:

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.

 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.

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?

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

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

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

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

"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

"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

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?

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

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?

Manu <turkeyman gmail.com> writes:

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

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

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

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

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

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

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

Manu <turkeyman gmail.com> writes:

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

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

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.

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

Guido Kollerie <guido kollerie.com> writes:

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=

y
 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

Manu <turkeyman gmail.com> writes:

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