Fixing const arrays

[Jakob Ovrum]

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.