On Monday, 12 December 2011 at 16:09:03 UTC, Andrei Alexandrescu
wrote:
On 12/12/11 9:29 AM, Jakob Ovrum wrote:
On Monday, 12 December 2011 at 15:14:02 UTC, Andrei
Alexandrescu wrote:
On 12/12/11 9:07 AM, Jakob Ovrum wrote:
If the programmer sees just "r.save", he
doesn't know whether it's a field or a property, and he
shouldn't need
to know, it should be fast and cheap, and return a
consistent value. As
far as I know, this isn't always true for save
Why? Save does behave like a field for the vast majority of
structs.
Andrei
But save is an abstract interface function, its signature
should reflect
all possible implementations.
Same goes for many properties.
Andrei
This is true, and many functions marked @property arguably
shouldn't be. I think it's a little like the reason
std.container.SList doesn't have a `length` property: the O(n)
complexity doesn't match the interface `length` exposes (although
formalised only in documentation/convention, not code).
If the standard library is allowed to assume `r.save` is a cheap
operation, in the same fashion it's allowed to assume this(this)
is cheap, then by all means, it makes sense as a property. The
only remaining arguments against it are purely about the name,
and I actually don't think that's relevant.
And just like you can still make a computationally expensive
this(this) when absolutely necessary, you can do the same with
save. If most reasonable uses of save have trivial performance,
it might as well be a property.
I'm still a beginner with ranges, but by my understanding and by
what some people made it sound like, reasonable uses of save
include some which are non-trivial. If this is true, then
removing @property from save encourages people to think more
about what using it might mean for the code they are writing,
which is definitely important.
