On 6/9/19 4:05 AM, Manu wrote:
> I am really really tired of this pattern:
> 
> struct DerivedStruct
> {
>      static if (BaseStruct.tupleof.length > 0)
>          BaseStruct base;
>      else
>          ref inout(BaseStruct) base() inout { return
> *cast(inout(BaseStruct)*)&this; }
>      alias base this;
> 
>      // derived members
>      //...
> }
> 
> Imagine if we could just write:
> 
> struct DerivedStruct : BaseStruct
> {
>      // derived members
>      //...
> }
> 
> Just imagine!
> 

Not necessarily objecting here, but does this pattern really come up all that often?

I'm not even entirely sure what's going on in the "static else" there. Is it just saying:

"If the BaseStruct is all methods and no data, then don't bother letting `BaseStruct base` add extra obviously-never-used bytes in DerivedStruct?"

If so, it sounds like maybe that's an optimization the language/compiler could/should be doing (semi-?)automatically?

On Sunday, 9 June 2019 at 19:04:50 UTC, Nick Sabalausky (Abscissa) wrote:
> I'm not even entirely sure what's going on in the "static else" there. Is it just saying:
>
> "If the BaseStruct is all methods and no data, then don't bother letting `BaseStruct base` add extra obviously-never-used bytes in DerivedStruct?"
>
> If so, it sounds like maybe that's an optimization the language/compiler could/should be doing (semi-?)automatically?

Structs are always at least 1 byte in size, even when they contain no fields. This causes unnecessary bloat for reasons that I never understood.

On 6/9/19 1:09 PM, KnightMare wrote:
> On Sunday, 9 June 2019 at 16:45:18 UTC, 12345swordy wrote:
> 
>> What is wrong with alias this?
> 
> in my mind "alias this" is a crutch that allow to move on, that tries to replace "has-a" with "is-a" and at the same time introduces an implicit conversion operator.

Sadly it was meant as a generalized "is-a". Implementation botched that, I'm afraid, beyond repair. We'd be better off deprecating it and allowing some simple form of subtyping for structs.

On 6/9/19 2:52 PM, Exil wrote:
> And? This is set in stone? There's no way to implement something better?

Have at it!

On Sunday, June 9, 2019 12:52:20 PM MDT Exil via Digitalmars-d wrote:
> On Sunday, 9 June 2019 at 18:43:01 UTC, Jonathan M Davis wrote:
> > On Sunday, June 9, 2019 12:19:34 PM MDT Exil via Digitalmars-d
> >
> > wrote:
> >> On Sunday, 9 June 2019 at 17:57:05 UTC, Jonathan M Davis wrote:
> >> > On Sunday, June 9, 2019 11:35:28 AM MDT KnightMare via
> >> >
> >> > Digitalmars-d wrote:
> >> >> On Sunday, 9 June 2019 at 17:26:40 UTC, SashaGreat wrote:
> >> >> >> PS need to allow edit post for 5min at at least
> >> >> >
> >> >> > Or you can:
> >> >> >
> >> >> > 1) Revise it better before posting.
> >> >> >
> >> >> > 2) If you use e-mail instead of WEB Front-End, some
> >> >> > e-mail services and applications (Like Thunderbird)
> >> >> > allows you to hold it for some time before sending.
> >> >>
> >> >> people make mistakes that can't be changed.
> >> >> 1) please dont write AI for people control system :)
> >> >> 2) too complicated.
> >> >> my suggestion (allow to edit post in next 5mins) is more
> >> >> humane.
> >> >
> >> > This is a newsgroup which can also be accessed via a web interface and via a mailing list. Once a message has been sent, it's been sent. It immediately goes out to everyone over the various interfaces, and it wouldn't make any more sense to try to edit your message after sending it than it would to try to edit an e-mail after you sent it to hundreds of people.
> >> >
> >> > - Jonathan M Davis
> >>
> >> Github also sends messages via email, you can even make replies by email. You can still edit them afterwards though.
> >
> > But no one gets those updates without looking at github, and even if they did, it would have to be via a new e-mail, cluttering things up. It's not possible for anyone to edit their message on github and then have the e-mails that everyone received update. The e-mails from github serve as notifications of what's on the website, not as the primary means of communication.
>
> That's because emails aren't suited for this type of communication. If you want to use emails, then yes you would then receive a second email. But if someone needs to make a correction anyways, they will need to send a second email as well. This not only clutters up the email but also the website as well. Which is what we have now.

Mailing lists have worked quite well for this type of communication for decades. So have newsgroups. And if you just reread what you're posting before you post it, you can avoid needing to edit it or send a response to your message to correct it. As it is, only a small percentage of posts in this newsgroup end up with the poster replying to correct their post.

> > And for D, the web interface is _not_ what controls the data. It's a client just like my e-mail client is and just like Walter's newsgroup client is. So, all it can edit is its local cache, which would make it out-of-sync with everyone else. Or it could send out a second message - which is exactly what you have to do right now. And because that's what you have to do, it doesn't give the false impression that you can edit previously sent messages.
> >
> > - Jonathan M Davis
>
> And? This is set in stone? There's no way to implement something better?

Many of us use the mailing list or newsgroup interfaces and have no interest in using the web interface. If the web interface can be improved in ways that work well with the newsgroup and the mailing list interfaces, then fine. Have at it. But editing messages really doesn't work well with that. And if you want to move away from the backend being a newsgroup with a mailing list as one of the interfaces, you're going to find a fair bit of opposition to that.

- Jonathan M Davis

On 09.06.19 20:52, Exil wrote:
> 
> And? This is set in stone? There's no way to implement something better?

Edit functionality is not "something better". It's perfectly fine that you can't retroactively change what you said in the past.

On Sunday, 9 June 2019 at 19:47:26 UTC, Andrei Alexandrescu wrote:

> Sadly it was meant as a generalized "is-a". Implementation botched that, I'm afraid, beyond repair. We'd be better off deprecating it and allowing some simple form of subtyping for structs.

I like the `alias this` feature quite a lot, but it does have a kludgy feeling to it when you get some experience with it.  For example, overload rules (or lack thereof).

I don't think of it so much as an "is-a" relationship, but more as a kind of mixin (for lack of a better word) where you mix the public interface of an aggregate's field with the public interface of the aggregate itself.   Though, now that I think of it, I wonder if that can be achieved with metaprogramming instead.  In that case, I'd probably prefer the metaprogramming technique.

I'm curious, though, so I welcome more elaboration on the shortcomings of the implementation.

Mike

On Monday, 10 June 2019 at 02:12:55 UTC, Mike Franklin wrote:

> For example, overload rules (or lack thereof).
>

Sorry, I mean resolution rules.

On 6/9/2019 12:40 PM, Vladimir Panteleev wrote:
> Structs are always at least 1 byte in size, even when they contain no fields. This causes unnecessary bloat for reasons that I never understood.


The reason is so that each struct instance is at a unique address.

There are some rules in C++ where sometimes a struct with no fields occupies 1 byte, sometimes 0 bytes. I don't recall what they are at the moment.

On Monday, 10 June 2019 at 03:08:26 UTC, Walter Bright wrote:
> On 6/9/2019 12:40 PM, Vladimir Panteleev wrote:
>> Structs are always at least 1 byte in size, even when they contain no fields. This causes unnecessary bloat for reasons that I never understood.
>
>
> The reason is so that each struct instance is at a unique address.
>
> There are some rules in C++ where sometimes a struct with no fields occupies 1 byte, sometimes 0 bytes. I don't recall what they are at the moment.

There is a (proposal?) for a no unique address attribute to disappear the address of structs the take up no room.