On Wednesday, 23 October 2013 at 22:12:50 UTC, Daniel Davidson wrote:
>> No, pure can't be specified as a block. You can only mark a function as
>> pure.

Any attribute can be specified as a block, as well as with colon notation.

On Thursday, October 24, 2013 00:12:48 Daniel Davidson wrote:
> 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@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 ... { ... }

You can use pretty much any attribute with a block or a :, so you can use a pure block, but it's almost always a bad idea to put pure, nothrow, @safe, or @trusted on a templated function, because whether the attribute is valid or not almost always depends on the template arguments. So, if you use such an attribute no a templated function, you restrict the types that will work with that function. Rather, templated functions infer pure, nothrow, and @safe, so in most cases, using those attributes on templated functions should be unnecessary.

Now, the template inferrence needs a lot of work, so it doesn't generally work on the more complicated cases yet (e.g. a struct declared inside of a templated function doesn't end up getting inferrence for its member functions like it should), but that will be fixed. That combined with the fact that several lower level constructs in druntime and Phobos still need some work to make them properly pure, nothrow, and/or @trusted/@safe makes it so that a lot less of Phobos is pure, nothrow, or @safe than should be the case. Progress is being made on that however (as evidenced by the fact that format can now be pure in the beta for 2.064).

- Jonathan M Davis

Jonathan M Davis:

> Progress is being made on that however (as evidenced by the
> fact that format can now be pure in the beta for 2.064).

Now two of the most common "offenders" of pure/nothrow in my high level code are iota() and arr.dup.

Bye,
bearophile

On Thu, Oct 24, 2013 at 12:12:48AM +0200, Daniel Davidson wrote:
> 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:
[...]
> >>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 ... { ... }

You're right. I didn't make myself clear: pure blocks are allowed but not inside a function, i.e., this isn't supported currently:

	void foo() {
		pure {
			...
		}
		...
	}

My bad.


[...]
> 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.
[...]

Thanks! Sorry I have to run now; I'll take a look at your code later, and perhaps try to track down the source of the purity error.


T

-- 
"I suspect the best way to deal with procrastination is to put off the procrastination itself until later. I've been meaning to try this, but haven't gotten around to it yet. " -- swr

On Thu, Oct 24, 2013 at 12:12:48AM +0200, Daniel Davidson wrote: [...]
> Here is the self-contained code (I hope) that you can see it
> happening in:
> http://pastebin.com/hb0Dz50r
[...]

Hmm. Somebody claimed that 2.064 beta has made text() pure, but that's
only partially true, because it calls to!(), and so its purity depends
on the purity of to!().  Unfortunately, to!() is NOT pure for many basic
types, including to!string(double.init). Furthermore, to!string(S) for
some struct S appears to be impure by default unless you manually define
a toString method that declares itself pure. Unfortunately,
to!string(DateTime.init) isn't pure either, which means that if your
struct contains DateTime and you need to format it then you're out of
luck.

So basically, text() is still practically unusable for anything that
isn't already trivially convertible to string (like string itself). Or
int -- apparently to!string(int.init) does work in pure code.

IOW, the purity of text() and to() still has a long ways to go before
user code can depend on it. :-(

Please file a bug in the bugtracker.

In the meantime, I'm going to track down exactly why to!string(double) isn't pure, since there's no valid reason why it can't be.


T

-- 
I am Ohm of Borg. Resistance is voltage over current.

On Thu, Oct 24, 2013 at 11:36:09AM -0700, H. S. Teoh wrote:
> On Thu, Oct 24, 2013 at 12:12:48AM +0200, Daniel Davidson wrote: [...]
> > Here is the self-contained code (I hope) that you can see it
> > happening in:
> > http://pastebin.com/hb0Dz50r
> [...]
> 
> Hmm. Somebody claimed that 2.064 beta has made text() pure, but that's
> only partially true, because it calls to!(), and so its purity depends
> on the purity of to!().  Unfortunately, to!() is NOT pure for many basic
> types, including to!string(double.init).
[...]
> In the meantime, I'm going to track down exactly why to!string(double) isn't pure, since there's no valid reason why it can't be.
[...]

So I traced the code down in Phobos, and discovered that the reason to!string(double.init) isn't pure is because it ultimately calls the C library snprintf to format floating-point values.

And the fact that it uses toString(scope void delegate(const(char)[])),
which can't be made pure because its purity depends on the purity of the
delegate, and currently the compiler has no way of inferring this, and
the language has no way to express this. :-(

Which means unless we rewrite large swaths of std.conv, making
text(double.init) pure isn't going to happen anytime soon. :-(


T

-- 
It is not the employer who pays the wages. Employers only handle the money. It is the customer who pays the wages. -- Henry Ford

On Thursday, 24 October 2013 at 00:02:30 UTC, bearophile wrote:
> Jonathan M Davis:
>
>> Progress is being made on that however (as evidenced by the
>> fact that format can now be pure in the beta for 2.064).
>
> Now two of the most common "offenders" of pure/nothrow in my high level code are iota() and arr.dup.
>
> Bye,
> bearophile

Is arr.dup really impure or is it something queued up to become pure?

Thanks
Dan

On Monday, October 28, 2013 13:40:03 Daniel Davidson wrote:
> On Thursday, 24 October 2013 at 00:02:30 UTC, bearophile wrote:
> > Jonathan M Davis:
> >> Progress is being made on that however (as evidenced by the fact that format can now be pure in the beta for 2.064).
> > 
> > Now two of the most common "offenders" of pure/nothrow in my
> > high level code are iota() and arr.dup.
> > 
> > Bye,
> > bearophile
> 
> Is arr.dup really impure or is it something queued up to become pure?

It's essentially a bug that the compiler does not consider it pure. Memory allocation is valid in pure functions, and dup is just as pure as new is. It can't be pure if copying the array's elements isn't pure (e.g. if the elements have impure postblits), but it can certainly be pure for the built-in types and any user-defined types for which copying is pure.

- Jonathan M Davis