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.
