www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - overloading function return

reply Chris Newton <Chris_member pathlink.com> writes:
Hello all,

First of all, forgive me if this has already been asked, it probably has.
Unfortunately there is no search option on the Newsguy News Service so I had to
give up on researching before asking. :)

Second of all, a little disclaimer. I'm a programmer, but I'm not a compiler
writer. I understand most of the high level concepts of languages/compilers, but
not all the implementation details and what works and what doesnt.

D has virtualy everything I have wanted in a language for a long long time. I'm
glad to have found it. But, it does not have the ability to overload the return
type. I see that it does have covariant returns, which is nice, but not quite
what I'm looking for. :) I have writen many a function in the form of something
like: intValue(), doubleValue(), charValue(), asSomeClass1(), asSomeClass2(),
etc etc etc.

It seems to me that the semantics should be checkable by looking at the type of
left hand side of the statement. I would expect normal casting rules to apply.
In fact, as they apply to function parameter overloading. :)

A note about the SomeClass1 and SomeClass2 classes, often they end up being
rooted under the same hierarchy. So you end up casting down the tree. Why not
follow the normal cast() semantics which returns null in case of it not being
that type. And of course the type being casted to would be defined as the type
of the lvalue. A null should be expected if you want to restrict the type and
not look at a base class and poke around.

Is there a reason its not included? I'm guessing there has to be since the
effort was made to include covariant returns.

Please forgive my lack of carnal compiler knowledge. :)

Chris Newton
Dec 27 2004
parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Chris Newton wrote:

 Hello all,
 
 First of all, forgive me if this has already been asked, it probably has.
 Unfortunately there is no search option on the Newsguy News Service so I had to
 give up on researching before asking. :)


Google search integrated into all digitalmars D pages is very eager to 
search the newsgroup web representation, in fact. And some proper 
newsreaders, such as Mozilla Thunderbird allow to search through subject 
lines, or if you also have an offline cache also inside messages.


 Second of all, a little disclaimer. I'm a programmer, but I'm not a compiler
 writer. I understand most of the high level concepts of languages/compilers,
but
 not all the implementation details and what works and what doesnt.


I don't think we have particularly many compiler writers here, so you're 
in a good company. :> The reference implementation is being maintained 
entirely by Walter, and there are 2 compiler ports maintained by one 
person each, and there are a couple more people which have prior 
compiler writing experience. And some wannabes including myself.


 D has virtualy everything I have wanted in a language for a long long time. I'm
 glad to have found it. But, it does not have the ability to overload the return
 type. I see that it does have covariant returns, which is nice, but not quite
 what I'm looking for. :) I have writen many a function in the form of something
 like: intValue(), doubleValue(), charValue(), asSomeClass1(), asSomeClass2(),
 etc etc etc.


You draw my attention to a sort-of problem. Covariant returns are not 
typesafe, only counter-variant ones are. Perhaps that is a misfeature to 
delete from the language. I don't have enough time to go through the 
matter myself, so i would hope someone really experianced (Norbert 
Nemec?) would look at this.


 It seems to me that the semantics should be checkable by looking at the type of
 left hand side of the statement. I would expect normal casting rules to apply.
 In fact, as they apply to function parameter overloading. :)


Yes, it would be. But in D there is are no features which look at the 
left side of the assignment. In particular, there is no implicit 
conversion operator for classes and structs, unlike in C++ - you can 
only overload an expicit cast operator. A particular consern is that 
this pretty much breaks when you don't use the function call directly in 
assignment but in an expression - for example where it may be an 
argument to an function or an operator, which, in turn may accept 
different types. It has been decided that D tries not to create 
ambiguous situations, and gives an error instead. However, even if there 
is an exact match, it is very brittle with respect to further additions 
- for example you add another implicit conversion or another return 
overload, this very well may create an ambiguity. In C++, just some of 
these conversion paths would be picked up by rules which are 
deterministic, but nearly impossible to follow by the human. Usual 
consequence would be possible loss of information. In D however, it 
would lead to an error since such ambiguities are forbidden by design - 
thus improving one piece of code would break many distant ones.

Furthermore, with such policy it wouldn't get better if one ignores the 
type of LHS or surrounding expression and requieres an expicit cast, 
because adding the first return overload to the library would requiere 
all users to modify their code and insert casts, which is hardly 
acceptable. Furthermore, you would be back to a notation similar to the 
one you are having already. And why the heck not use the out parameter 
of functions? Another aspect is that D, like C or C++, doesn't force you 
to use the return value, you may very well throw it away - but then you 
have no criterium on which to select a return-overloaded function, 
unless a dummy cast is issued.

Matthew Wilson and some of other experienced C++ professionals, have 
made themselves a habit to forbid implicit conversions in C++, because 
they have experienced such problems. I suggest you google for Matthew's 
articles on shims.


 A note about the SomeClass1 and SomeClass2 classes, often they end up being
 rooted under the same hierarchy. So you end up casting down the tree. Why not
 follow the normal cast() semantics which returns null in case of it not being
 that type. And of course the type being casted to would be defined as the type
 of the lvalue. A null should be expected if you want to restrict the type and
 not look at a base class and poke around.


There is quite a difference. An explicit cast stands out by being a 
keyword, and alerts the reader that this spot may yuild null, which is 
an illegal value to work with. If any innocently looking expression 
could have an implicit cast which could produce illegal values which 
only show up some time later, it would be nearly impossible to debug 
because it would be totally unclear where this illegal value may have 
come from.


 Is there a reason its not included? I'm guessing there has to be since the
 effort was made to include covariant returns.


There are many reasons. The first one is that the master-plan is to get 
the language out and running polished, in a minimal version, get a broad 
user base, and library support, and then add some more features, 
including many totally new to languages in more or less broad use today. 
It is important now not to introduce features we may regret, but further 
on, after 1.0, if you show the feature is desired and moderately safe, 
it can probably be added. Another feature that Walter was going to look 
at for D 2.0 is an ability to hack into the parser and extend language 
with new features by writing libraries or compiler plug-ins.


 Please forgive my lack of carnal compiler knowledge. :)


It's not about compiler knowledge. And that's what the newsgroup is for, 
to ask for when in doubt.

-eye
Jan 07 2005
next sibling parent reply Norbert Nemec <Norbert Nemec-online.de> writes:
Ilya Minkov wrote:


 You draw my attention to a sort-of problem. Covariant returns are not
 typesafe, only counter-variant ones are.


Actually, this is not correct: Return types are covariant, while function
arguments are contravariant. To illustrate:

----------------------
// To illustrate covariance of returntypes
class Object {
}

class Car: Object {
}

class Factory {
 Object produce();
}

class CarFactory {
 Car produce();
}
-----------------------
// To illustrate contravariance of arguments
class Beverage {
}

class Water: Beverage {
}

class Animal {
 void drink(Water);
}

class DonaldDuck: Animal {
 void drink(Beverage);
}
-----------------------


 Perhaps that is a misfeature to delete from the language.


No it is very fundamental part of the concept of inheritance. An object of
the inheriting class can be used in any place where an object of the parent
class is expected. To perfectly "mimic" a parent object, it must "eat"
anything the parent can eat and may not produce anything that the parent
would not produce.

To explain the terms: "covariant" means, the "variation" of the type goes in
the same direction as the inheritance of the class, "contravariant" means,
it runs in the opposite direction.

(Besides from that, the answer if Ilya seems perfectly correct to me.)
Jan 09 2005
parent Ilya Minkov <minkov cs.tum.edu> writes:
Norbert Nemec wrote:

 Ilya Minkov wrote:
 

You draw my attention to a sort-of problem. Covariant returns are not
typesafe, only counter-variant ones are.


 
 Actually, this is not correct: Return types are covariant, while function
 arguments are contravariant. To illustrate:


Ah, thank you for not letting me stray any misinformation out here. :> I 
had the impression that i could get it wrong, and i did mix it all up 
finally.


 ----------------------
 // To illustrate covariance of returntypes


8< --- >8


 No it is very fundamental part of the concept of inheritance. An object of
 the inheriting class can be used in any place where an object of the parent
 class is expected. To perfectly "mimic" a parent object, it must "eat"
 anything the parent can eat and may not produce anything that the parent
 would not produce.


Oh, true. I got dried too much in the invariance of a certain other 
language.

And thanks for confirming that D gets it right.

-eye
Jan 09 2005
prev sibling parent reply novice2 <novice2_member pathlink.com> writes:
In article <crn0kg$p7$1 digitaldaemon.com>, Ilya Minkov says...


Google search integrated into all digitalmars D pages is very eager to 
search the newsgroup web representation, in fact. And some proper 


Sorry for offtopic and my stupidity.
Ilya, can you say a bit more about "Google search integrated into all
digitalmars D pages"? How i can use it? Google link "search in group"
http://groups.google.com/groups?.... don't work with "digitalmars.D" group :(
Jan 12 2005
parent reply Carotinho <carotinobg yahoo.it> writes:
Hi!

novice2 wrote:


 Sorry for offtopic and my stupidity.
 Ilya, can you say a bit more about "Google search integrated into all
 digitalmars D pages"? How i can use it? Google link "search in group"
 http://groups.google.com/groups?.... don't work with "digitalmars.D" group
 :(


I think he refers to the Google search utility in DigitalMars main page, to
the top right. You can select whether to search the web or the site.

Byez!

Carotinho
Jan 12 2005
parent novice2 <novice2_member pathlink.com> writes:
I think he refers to the Google search utility in DigitalMars main page, to
the top right. You can select whether to search the web or the site.


Thank you very march, Carotinho!
Where was my eyes?
I always need any search on this forum.

Thanks.
Jan 13 2005