Accessors, byLine, input ranges

[Steven Schveighoffer]

On Fri, 29 Jan 2010 12:23:24 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> Steven Schveighoffer wrote:
>> On Fri, 29 Jan 2010 11:29:22 -0500, Andrei Alexandrescu  
>> <SeeWebsiteForEmail at erdani.org> wrote:
>>
>>> Steven Schveighoffer wrote:
>>>> On Fri, 29 Jan 2010 11:21:28 -0500, Andrei Alexandrescu  
>>>> <SeeWebsiteForEmail at erdani.org> wrote:
>>>>
>>>>> How is f.byLine clearer and less ambiguous than f.byLine()? Or vice  
>>>>> versa for that matter?
>>>>  Note that properties can be named things other than byLine.
>>>>  -Steve
>>>
>>> What I meant to say is that in the @property landscape the following  
>>> two conventions become suddenly attractive:
>>>
>>> * Do not use @property at all
>>>
>>> * Use @property for all nullary functions
>>>
>>> And they're bound to save a lot of time to everyone involved.
>>>
>>  I think we all agree that setters the way D1 does them are very prone  
>> to abuse.  So all that is left is no-argument functions.
>>  There are other alternative conventions to what you stated.  This is  
>> my convention:
>>  * use @property where the main purpose of the function is to fetch a  
>> value (computed or not, modifying the container or not)
>
> Consider:
>
> struct Stack(T) {
>      T pop();
>      ...
> }
>
> By your definition, pop() should be a property. It doesn't quite strike  
> me as an intuitive decision.

is pop's main purpose to fetch a value or to modify the stack?  I'd say  
the purpose is split equally, so it's not a function whose main purpose is  
to fetch a value.  I admit this is a good example where a judgement call  
comes into play, but we aren't all robots obeying every rule literally.   
There are sometimes exceptions in conventions, or at least the rule is  
subject to interpretation.

-Steve