Accessors, byLine, input ranges

[Pelle Månsson]

On 01/29/2010 07:23 PM, Ary Borenszweig wrote:
> Andrei Alexandrescu wrote:
>> Ary Borenszweig wrote:
>>> Andrei Alexandrescu 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.
>>>
>>> The first post of this thread was about not invoking a function when
>>> you don't want it to be invoked. bearophile was doing:
>>>
>>> auto dg = int function() { ... };
>>> return dg;
>>>
>>> but he wanted to return a reference to dg, not the result of invoking
>>> it. One way to prevent that is to never invoke functions unless they
>>> are marked with @property. Or maybe functions defined like that
>>> (closures, whatever) should always require () to be invoked.
>>>
>>> If that doesn't sound reasonable, see this:
>>>
>>> auto dg1 = int function() { ... };
>>> auto dg2 = dg1;
>>>
>>> I'd expect dg2's type to be dg1's type.
>>>
>>> Let's just think a solution to this problem first. :-)
>>
>> Correct. Just that I fear that it's a bit late for this all. It is
>> disheartening enough that Walter got convinced by the past discussion
>> and introduced @property without much design - after a FAILED vote no
>> less. I strongly believe a better solution is available, but everyone
>> wanted the feature so the feature just got born.
>>
>> FWIW, my take for issues like the above: if a function returns a
>> function or a delegate, it can't avail itself of automatic invocation
>> of "()". That takes care of a corner case and keeps the mainstream
>> case in good shape.
>>
>> I am not sure of a good solution for problems like
>>
>> writeln = 2;
>
> I think at least for the function/delegate problem, requiring () to
> invoke it might be good.
>
> int foo() { ... }
>
> auto dg1 = bool function() { ... };
> auto x = dg1; // x is bool function()
> auto y = dg1(); // y is bool
>
> auto dg2 = &foo;
> auto z = dg2; // z is int function()
> auto w = dg2(); // z is int
>
> The only thing that remains "problematic" is this one:
>
> auto dg3 = foo; // It's int. To take the address use &
> // but might lead to unexpected results
> // when using "auto"

If () is required to invoke delegates, that isn't a problem. First use 
will tell on it.