User defined properties signatures

[dvic via Digitalmars-d-learn]

On Monday, 20 April 2015 at 18:50:31 UTC, Jonathan M Davis wrote:
> On Monday, April 20, 2015 18:35:34 dvic via Digitalmars-d-learn 
> wrote:
>> Hi guys,
>>
>> It seems it's possible to define different read properties, 
>> only
>> differing by the return type.
>
> Not possible. Just like pretty much any C-derived language 
> (C++, Java, C#,
> etc.) the return type of a function is not considered in 
> function
> overloading, and it is illegal to overload a function based on 
> its return
> type.
>
>> Why is the compiler not complaining about defining 2 read
>> properties and it does
>> otherwise when using both of them?
>
> Now, that is weird. I would fully expect something like
>
> struct S
> {
>     @property int foo() { return 7; }
>     @property string foo() { return "foo"; }
> }
>
> to result in an error, but for some reason, it doesn't (and it 
> doesn't seem
> to have anything to do with the fact that it's a property 
> function). I have
> no idea why and would be inclined to argue that it's a compiler 
> bug (though
> a compiler dev may be able to come up with a good reason for 
> why it's acting
> the way it is). However, since it _is_ failing to compile as 
> soon as you use
> the function, the only real problem is that if you declare a 
> function
> without ever testing it, you risk having a duplicate function 
> without
> knowing it.  But still, I really think that the compiler should 
> be giving an
> error message even if you don't call it.
>
> - Jonathan M Davis


Thanks for your answer Jonathan. But does the return type part of 
a method
signature? I don't know what theory is claiming about that, but 
for me they
are 2 different methods. So contextually, the best fit should 
prevail.