This is a low-priority request, maybe a long-term one. With dmd 2.048 this program shows that to!() is not pure: test.d(3): Error: pure function 'main' cannot call impure function 'to' import std.conv: to; pure void main() { to!int("1"); } But in theory the to!() doesn't need to change its inputs, and its output is deterministic and fully determined by the input value. So eventually to!() may become pure, so you may use it inside pure functions too.
std.conv.to is not pure due to the following function and bugs. The conversions which trigger them are listed below. 1. std.array.appender - array -> string - AA -> string - struct -> string 2. memcpy - void[] -> string 3. std.exception.enforce (bug 5750) - void[] -> string - integer & radix -> string 4. the .toString member method is not necessarily pure - class/struct -> string 5. std.conv.to itself is not pure - array -> string - AA -> string - struct -> string - enum -> string - typedef -> string - bool -> string - array -> array - AA -> AA - integer -> string - floating -> string - pointer -> string 6. std.conv.parseString - string -> string 7. the .to!T member template method is not necessarily pure - class -> any 8. std.conv.ConvOverflowException.raise (bug 3269, should have been fixed) - numeric -> numeric 9. 'pure nested function '__foreachbody2115' cannot access mutable data 'first'' (bug 5635). 10. core.memory.GC.malloc (why not use 'new Char[x]'?) - uint/ulong -> string 11. sprintf - [i,c]double/real -> string std.conv.parseString is not 'pure' because convError and parse are not 'pure'. convError is not 'pure' because it uses to!string. parse is not pure due to the following: 12. ConvOverflowException.raise 13. convError 14. std.algorithm.skipOver - string -> enum 15. std.conv.to (including std.conv.text) - string -> floating 16. std.exception.enforce 17. 'static const int sign = 0;' near line 1109, should be immutable? 18. std.math.ldexpl - string -> floating 19. std.algorithm.skipAll - string -> array 20. std.string.icmp - string -> bool std.conv.to itself cannot be fully pure, because of #4 (.toString) and #7 (.to!T), unless we require user's .toString must be 'pure' as well, which is not necessarily possible (considering even making 'opEquals' const is debatable). Therefore, the compiler or library must support some form of 'auto pure' for 'to' to choose the strictest attribute automatically/programmatically. This also applies to the two 'std.algorithm' functions (#14 skipOver, #19 skipAll) which can run user code. But a problem of 'auto pure' is dealing with recursive functions, which happens a lot here (#5, #15). And then there are some functions like #1 (appender), #10 (GC.malloc) which I wonder should they be really 'pure', and avoiding them could reduce efficiency a lot.
and of course it requires several functions in std.utf and the range primitives in std.array be pure, which I have addressed in Phobos pull #80 (https://github.com/D-Programming-Language/phobos/pull/80).
Thank you for your work. There is a large number of functions in Phobos and druntime that will need to be tagged as pure. The pure attribute increases the complexity of D language, so tagging with pure as many Phobos/druntime functions as possible is a way to make it pay for the added complexity.
*** Issue 3437 has been marked as a duplicate of this issue. ***
In 2.064a, the issue has been fixed. https://github.com/D-Programming-Language/phobos/pull/1337 https://github.com/D-Programming-Language/phobos/commit/4da1639c98cb73d07858b17c2d225063889e4700