D is dead

[Steven Schveighoffer]

On 8/23/18 9:22 AM, Shachar Shemesh wrote:

> On the other hand, look at ConnectedSocket.connect:
> https://weka-io.github.io/mecca/docs/mecca/reactor/io/fd/ConnectedSocket.connect.html 
> 
> 
> Why do I need two forms? What good is that? Why is the second form a 
> template? Answer: Because in D, structs can't inherit, and I cannot 
> define an implicit cast. What I'd really want to do is to have 
> SockAddrIPv4 be implicitly castable to SockAddr, so that I can pass a 
> SockAddrIPv4 to any function that expects SockAddr.
> 
> Except what I'd _really_ like to do is for them to be the same thing. 
> I'd like inheritance. Except I can't do that for structs, and if I 
> defined SockAddr as a class, I'd mandate allocating it on the GC, 
> violating the whole point behind writing Mecca to begin with.

So interestingly, you are accepting the sockaddr by VALUE. Which 
eliminates any possibility of using inheritance meaningfully anyway 
(except that depending how you define SockAddr, it may include all the 
data of the full derived address, sockaddr is quirky that way, and NOT 
like true inheritance).

You CAN use inheritance, just like you would with classes, but you have 
to pass by reference for it to make sense

struct SockAddr
{
    int addressFamily; // forget what this really is called
    ...
}

struct SockAddrIPv4
{
    SockAddr base;
    ref SockAddr getBase() { return base; }
    alias getBase this;
    ...
}

Now, you can pass SockAddrIPv4 into a ref SockAddr, check the address 
family, and cast to the correct thing. Just like you would with classes 
and inheritance. You can even define nice mechanisms for this.

e.g.:

struct SockAddr
{
    ...
    ref T cast(T)() if (isSomeSockaddr!T)
    {
       assert(addressFamily == T.requiredAddressFamily);
       return *cast(T*)&this;
    }
}

> To summarize: Weka isn't ditching D, and people aren't even particularly 
> angry about it. It has problems, and we've learned to live with them, 
> and that's that.

This sounds more like what I would have expected, so thank you for 
clarifying.

> The general consensus, however, is that these problems 
> will not be resolved (we used to file bugs in Bugzilla. We stopped doing 
> that because we saw nothing happens with them), and as far as the future 
> of the language goes, that's bad news.

Bugs do get fixed, there is just no assigned timeframe for having them 
fixed. An all volunteer workforce has this issue.

It took 10 (I think) years for bug 304 to get fixed. It was a huge pain 
in the ass, but it did get fixed.

I wouldn't stop filing them, definitely file them. If they are blocking 
your work, complain about them loudly, every day. But not filing them 
doesn't help anyone.

I'm not saying all bugs you file will be fixed, but all bugs you *don't* 
file will definitely not be fixed.

-Steve