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

[Michel Fortin]

On 2010-02-28 18:42:50 -0500, Pelle Månsson <pelle.mansson at gmail.com> said:

> On 02/28/2010 10:01 PM, Michel Fortin wrote:
>> If you want a rationale, I think it'd be fine to say that attributes are
>> things you can ignore because they only have a restrictive effect on the
>> semantics (the definition you said you invented). Then mention there is
>> an exception: @property.
> 
> 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.


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/