conv text and pure

[Daniel Davidson]

On Wednesday, 23 October 2013 at 21:37:25 UTC, H. S. Teoh wrote:
> On Wed, Oct 23, 2013 at 11:17:30PM +0200, Daniel Davidson wrote:
>> On Wednesday, 23 October 2013 at 20:18:39 UTC, Andrej Mitrovic
>> wrote:
>> >On 10/23/13, Daniel Davidson <nospam at spam.com> wrote:
>> >>Great, thanks. What is the best way to get on that version 
>> >>for the
>> >>Mac (pointer to instructions)?
>> >
>> >You can download the beta here:
>> >http://forum.dlang.org/thread/52605C84.6010109@walterbright.com
>> 
>> Thanks for pointer. I am using it and the file conv.d has:
>> 
>> string text(T...)(T args) { return textImpl!string(args); }
>> 
>> 
>> So, when you say it is pure, what are you referring to. I 
>> think pure
>> could be specified as a block, but when I search up the next 
>> prior
>> pure occurrence is:
>>   @safe pure unittest
>
> No, pure can't be specified as a block. You can only mark a 
> function as
> pure.
>

I think that is not correct. Consider:

int x = 3;
struct S {
   pure {
     void foo() {
       //x = 4;
     }
   }
}

pure blocks seem to have the effect you would expect. In fact it 
seems like you can stream them together to make code more 
pleasant:

const pure ... { ... }



> Furthermore, the above function is a template function, which 
> means the
> compiler will perform attribute inference on it. So provided 
> textImpl
> has no impure operations, it should be inferred as pure, unless 
> args has
> some impure methods in it that's being used by textImpl.
>
>
>> So I don't think it is in a pure block. Also I still get:
>> 
>> Error: pure function 'plus.utils.history.History!(const(S), 
>> "a.date
>> < b.date").History.opOpAssign!("~", S).opOpAssign' cannot call
>> impure function 'std.conv.text!(string, string, const(S), 
>> string,
>> const(S)).text'
>> 
>> So, I am still looking for workaround if possible and answers 
>> to the
>> general questions on pure.
> [...]
>
> OK, I'm looking at the implementation of textImpl in 
> std/conv.d, and it
> seems that the only thing it does is to call to!string(...) on 
> each of
> its arguments, and append the result to a local variable called
> 'result'. Since array appending is pure (otherwise we have major
> problems with D purity), the only culprit seems to be the calls 
> to
> to!string().
>
> What arguments are you passing to text()? Do all of them have 
> toString
> methods that are marked pure? Keep in mind that the default 
> toString
> implementation (e.g. inherited from Object) may not necessarily 
> be
> marked pure, so that could be the cause of your problems here.
>
> It would be nice if you could provide a suitably minimized 
> version of
> your code that exhibits this purity issue, so that we can track 
> it down.
> It's kinda hard to figure out what's wrong based on verbal 
> descriptions
> alone. (I apologize if you've already posted said code; I've 
> been too
> busy to keep up with every post in this forum.)
>
>

Here is the self-contained code (I hope) that you can see it 
happening in:
http://pastebin.com/hb0Dz50r

BTW: any and all constructive criticism on any aspect of code is 
welcome.

I have not previously posted this code, but per your request on a 
previous thread 
(http://forum.dlang.org/post/xvymqxecgmkyvpvegird@forum.dlang.org) 
I did post sample code of struggles with immutable members. I've 
since mostly given up on immutable members (partially on your 
explanations and reasoning) and therefore immutable in general 
and so I find it's presence in the language like grapes to 
Tantalus. Not sure why I'm even fighting for purity since my main 
purpose for it originally was to allow for easy creation of 
immutable(T).

Thanks
Dan