Ilya Minkov 
Posted in reply to Chris Newton
| 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
|
Permalink
Reply
