Fixing const arrays

[Mehrdad]

On 12/11/2011 2:56 AM, David Nadlinger wrote:
> On 12/11/11 10:04 AM, Mehrdad wrote:
>> On 12/11/2011 12:57 AM, Andrei Alexandrescu wrote:
>>> I think you should write:
>>>
>>> auto copy = this.save;
>>
>> Ah good point, I forgot about that. Idk then.
>> (You forgot the parentheses though. :P)
>
> No, it's correct like that, save() is a @property.
>
> Even though I recently updated Phobos to compile with -property 
> enabled, I agree with Andrei here that in many cases there will be no 
> perfect consensus whether a given member should be a @property or not, 
> thus potentially adding an extra source of complexity, or rather 
> annoyance.
>
> David

Whoa what?! I didn't know save() is a @property. In that case I stand 
corrected. :-)

Nevertheless, I think that makes no sense. :P If something isn't a 
"property" of something else, it shouldn't be marked as such.

But there are more reasons than that...

I have found Microsoft's guidelines for C# to be great for general usage 
of the word @property:
http://msdn.microsoft.com/en-us/library/ms182181.aspx

Specifically:

"Properties should behave as if they are fields; if the method cannot, 
it should not be changed to a property.
Methods are better than properties in the following situations:

- Calling the method two times in succession creates different results.
- The method performs a time-consuming operation. The method is 
perceivably slower than the time that is required to set or get the 
value of a field."

Since both of these can be true for all but the most trivial kinds of 
ranges (e.g. file-system-related enumerators/ranges would very likely 
need to re-open a handle to a directory in order to traverse it, which 
is both relatively time-consuming AND returns a different result every 
time, and could even unexpectedly fail due to permission/connectivity 
issues), I don't think it makes sense for save() to be a @property.