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 <nos...@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.6010...@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/xvymqxecgmkyvpveg...@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
