byKey and byValue: properties or methods?

[Timon Gehr]

On 01/19/2012 01:38 AM, Alex Rønne Petersen wrote:
> On 19-01-2012 01:41, Peter Alexander wrote:
>> On 18/01/12 12:52 AM, Timon Gehr wrote:
>>> On 01/18/2012 01:40 AM, Jonathan M Davis wrote:
>>>> On Tuesday, January 17, 2012 19:31:25 bearophile wrote:
>>>>> Nick Sabalausky:
>>>>>> Without properties, member function access *ANY* many value
>>>>>> accesses are "a.b()". Is this member value a plain-old-var or a
>>>>>> function?
>>>>>> Who knows! It's a leeked out implementation detail, hooray!
>>>>>
>>>>> I have a partially related question.
>>>>>
>>>>> Currently this code compiles even with -property:
>>>>>
>>>>> void main() {
>>>>> int[int] aa = [1:2];
>>>>> auto byval = aa.byValue();
>>>>> }
>>>>>
>>>>> But I think byValue is a property, so isn't it right to give a
>>>>> compilation
>>>>> error if you add () after the name of a property?
>>>>
>>>> Definitely a bug. Strict enforcement requires that parens be used on
>>>> all
>>>> function calls and that no properties use parens. If you use parens on
>>>> them,
>>>> that would mean that you're using them on the return value of the
>>>> property
>>>> (e.g. opCall) - and in fact, that's one of the main reasons that
>>>> @property was
>>>> added in the first place, since without enforcement, property
>>>> functions which
>>>> return a delegate result in an ambiguity.
>>>>
>>>> - Jonathan M Davis
>>>
>>> A related and way more embarrassing problem is that lazy function
>>> parameters have the same issue.
>>>
>>> This program prints nothing:
>>> import std.stdio;
>>> void foo(lazy void delegate() dg){
>>> dg();
>>> }
>>> void main(){
>>> foo({writeln("hello");});
>>> }
>>
>> Perhaps I'm wrong, but this issue is different.
>>
>> The code you have written is something that would be written by someone
>> that doesn't understand how lazy works. You have to use () to un-lazy
>> it, and then () again to invoke the delegate. There is no ambiguity like
>> there is with property delegates.
>
> But couldn't that be considered leaking an implementation detail of lazy
> values? Or is this intentional design?
>

I suppose it is an implementation relic.