On Wed, 29 Dec 2010 15:38:27 -0500, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
On 12/29/10 2:10 PM, Steven Schveighoffer wrote:
On Wed, 29 Dec 2010 14:42:53 -0500, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
On 12/27/10 6:55 PM, Andrei Alexandrescu wrote:
On 12/27/10 12:35 PM, bearophile wrote:
Through Reddit I have found a link to some information about the Clay
language, it wants to be (or it will be) a C++-class language, but
it's not tied to C syntax. It shares several semantic similarities
with D too. It looks like a cute language:
https://github.com/jckarter/clay/wiki/
[snip]
FWIW I just posted a response to a question asking for a comparison
between Clay and D2.
http://www.reddit.com/r/programming/comments/es2jx/clay_programming_language_wiki/
That thread is shaping up more and more interesting because it's
turning into a discussion of generic programming at large.
I wanted to address your post in the reddit discussion regarding the
issue of operator overloads not being virtual:
"This non-issue has been discussed in the D newsgroup. You can implement
virtuals on top of non-virtuals efficiently, but not vice versa."
I've found some very real problems with that, when implementing operator
overloads in dcollections. It's forced me to use the (yet to be
deprecated) opXXX forms. Specifically, you cannot use covariance with
templated functions without repeating the entire implementation in the
derived class.
Glad you're bringing that up. Could you please post an example that
summarizes the issue?
With D1:
interface List
{
List opCat(List other);
}
class LinkList : List
{
LinkList opCat(List other) {...}
}
With D2:
interface List
{
List doCat(List other); // implement this in derived class
List opBinary(string op)(List other) if (op == "~")
{ return doCat(other); }
}
class LinkList : List
{
LinkList doCat(List other) {...}
}
// usage;
LinkList ll = new LinkList(1, 2, 3);
ll = ll ~ ll; // works with D1, fails on D2, "can't assign List to
LinkList"
Solution is to restate opBinary in all dervied classes with *exact same
code* but different return type. I find this solution unacceptable.
Also, let's not forget, templates can't be used in
interfaces, which means no operator overloading in interfaces.
Interfaces allow final methods which should help.
operator overloads *must* be templates, and templates aren't allowed, so
final methods don't help here. Actually, final methods can't forward
covariance either, so we have issues there. I think we need a general
solution to the covariance problem. I also have filed a separate bug on
covariance not being forwarded by alias.
Related bug:
http://d.puremagic.com/issues/show_bug.cgi?id=4174
That should be what the doctor prescribed. I updated the report and
assigned it to Walter.
I saw, thanks.
-Steve
