A rationale for pure nothrow ---> @pure @nothrow (and nothing else changes)

[Pelle Månsson]

On 03/01/2010 01:29 AM, Michel Fortin wrote:
> On 2010-02-28 18:42:50 -0500, Pelle Månsson <pelle.mansson at gmail.com> said:
>>
>> Sorry if I go on and miss the point some more, but I dislike this a
>> lot. That's imposing restrictions on future @attributes. Like, for
>> example, @memoized. Or something like that. @traced, maybe.
>
> If I'm not mistaken about your intention, making a function @memoized
> wouldn't change its semantics. It'd change how it is optimized, but both
> from the caller perspective and for the one who write the function's
> implementation, it's totally transparent. Well, not exactly: it puts
> some restrictions for the function's body, same as purity I believe.
>
> So someone who just want to understand how a program works can ignore
> @memoized when looking at it (at least until he wants to look at the
> optimizations).
>
> The difference with @property is that it changes how you call it, it's
> not a transparent change at all.
>
>
>> This is me envisioning user-defined @attributes, really. They can
>> reduce boilerplate and increase flexibility in cases like @traced.
>
> Not sure what you mean about @traced. If you mean that any call to a
> function is logged somewhere, then I don't see that as a change in
> semantics neither for the caller nor for the one who write the function,
> so it'd have no problem having that as an attribute.

I seem to have misunderstood your intentions. I think I am clearer on 
what you mean now.

What about @curried? It (potentially) changes the way the function is 
called, yet looks quite good as an @attribute.