Is @property implementable?

[Jacob Carlborg]

On 2011-03-03 08:16, Jonathan M Davis wrote:
> On Wednesday 02 March 2011 23:12:43 %u wrote:
>>> Well, it wouldn't be universal then. For a function to be treated
>>
>> as a property, it would require an annotation, but universal
>> function call syntax isn't supposed to require an annotation any
>> more than calling a function on an array as if it were a member
>> function requires an annotation. It's supposed to work with any
>> function.
>>
>> So are you saying a hypothetical function like
>>
>>      char[] strcpy(char[] destination, const char[] source);
>>
>> should be callable like:
>>
>>      myString.strcpy(myString2);
>>
>> ?
>>
>> Isn't that asking for disaster, since it does the exact opposite of
>> what the user expects (since the source and destination are
>> switched)?
>>
>> I think we need an annotation for this (even for arrays), since
>> otherwise it's too easy to go wrong.
>
> How are the destination and source switched? The arguments are in the exact same
> order, only now one of them is to the left of the function name. It's been like
> this with arrays for a long time. It's not going away, and it's not going to
> require an annotation. That would be a big change to the language, and the
> ability to call arrays like this is well-liked and often-used. And a number of
> people definitely want uniform function call syntax to be implemented so that it
> works for all types.
>
> I don't see what's easy to go wrong with this syntax. It's quite
> straightforward. It's been around for quite a while. And it's well-liked. It's
> not going to be changed. The only question is whether it's ever going to be
> implemented for types in general.
>
> - Jonathan M Davis

What I think he means is, if you see a function call like this:

myString.strcpy(myString2);

You would expect "myString" to be the source and "myString2" the 
destination.

-- 
/Jacob Carlborg