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

 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