std.conv.to purity

Brad Roberts via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Sat Feb 14 15:03:31 PST 2015


While snprintf might be one thing that provides to be an interesting 
obstacle, the better answer to why std.conv.to isnt pure is that no one 
has invested the time to work through issues like that to make it so. 
It _should_ be pure.

On 2/14/2015 12:32 PM, ketmar via Digitalmars-d-learn wrote:
> On Sat, 14 Feb 2015 19:59:58 +0000, Gary Willoughby wrote:
>
>> On Saturday, 14 February 2015 at 12:24:51 UTC, ketmar wrote:
>>> On Sat, 14 Feb 2015 11:29:28 +0000, Jack Applegame wrote:
>>>
>>>> why std.conv.to is not pure?
>>>>
>>>> string foo(real v) pure { return v.to!string; }
>>>> // Error: pure function 'foo' cannot call impure function
>>>> 'std.conv.to!string.to!(real).to'
>>>
>>> 'cause float->string conversion is damned hard task. to perform this
>>> conversion `to!` falls back to `formatValue` from "std.format",
>>> which in turn using `snprintf()` from libc.
>>
>> Forgive me being a bit dense but that doesn't necessarily mean it's
>> impure though, right?
>
> yes, you are right, it *may* be pure. yet `snprintf()` can't be marked as
> `pure`, so it contaminates everything. and there are no guarantees that
> `snprintf()` is pure even for known arguments (compiler can't prove that,
> and libc is free to do any funny things in it), so it will be wrong to
> just force-reimport it as `pure`.
>
> tl;dr: we need native D float->string converter to allow purity in this
> case. you are free to force-hack purity flag on function if you want, but
> this can be wrong and may lead to various heisenbugs.
>
> native pure D converter will also allow CTFE, btw, which is impossible
> now.
>


More information about the Digitalmars-d-learn mailing list